issued SBD_D SW-03_rebidding_rus (1)

ДОКУМЕНТАЦИЯ
ДЛЯ ТОРГОВ (ОДНОСТАДИЙНЫХ)
Выпущена: 3 сентября 2015 года
Поставка
медицинских информационных
систем для организаций
здравоохранения РК
ПУТ №:KHSTTIRP-D/SW-03- повторный
Проект: по передаче технологий и проведению
институциональной реформы в секторе
здравоохранения Республики Казахстан
Покупатель: Министерство здравоохранения и
социального развития Республики Казахстан
АСТАНА 2015
СОДЕРЖАНИЕ
Приглашение к участию в торгах (ПУТ)……………………………………………………………………3
Раздел I. Инструкции участникам торгов (ИУТ) ...........................................................9
Перечень статей .................................................................................................................9
Раздел II. Информационная карта конкурсного предложения (ИККП)....................1
Раздел III. Правомочность стран для предоставление Товаров, Работ и Услуг в
рамках закупок, финансируемых Банком ........................................................................9
Раздел IV. Общие условия контракта .............................................................................10
Раздел V. Специальные условия контракта (СУК) ...................................................100
Раздел VI. Технические требования ..............................................................................119
Раздел VII. Образцы форм ..............................................................................................129
Пояснения по работе с Образцами форм, предназначенные для Участников торгов602
Перечень Образцов форм ..............................................................................................606
3
Приглашение к участию в торгах (ПУТ)
Республика Казахстан
Проект по передаче технологий и проведению институциональной реформы
в секторе здравоохранения Республики Казахстан
Единая информационная система здравоохранения
Займ 4883 –KZ
Поставка медицинских информационных систем
для организаций здравоохранения РК
ПУТ №: KHSTTIRP-D/SW-03-повторный
1.
Настоящее Приглашение к участию в торгах (ПУТ) соответствует Общему
уведомлению о закупках (ОУЗ) для данного проекта, которое было опубликовано на
сайте «DevelopmentBusiness» № 2633470 от 02 июня 2008 года.
2.
Республика Казахстан получила заем от Международного банка реконструкции
и развития в счет стоимости Проекта по передаче технологий и проведению
институциональной реформы в секторе здравоохранения Республики Казахстани
намерен использовать часть средств этого займа для финансирования платежей по
контракту
KHSTTIRP-D/SW-03-повторный
«Поставка
медицинских
информационных систем для организаций здравоохранения РК», состоящего из
следующих лотов:
Лот № 1 «Поставка и внедрение комплексной медицинской информационной
системы для Усть-Каменогорской городской больницы №1»;
Лот № 2 «Поставка и внедрение комплексной медицинской информационной
системы для ГКП на ПХВ «Городская клиническая больница №4» г.Алматы»;
Лот № 3 «Поставка и внедрение комплексной медицинской информационной
системы для Центра матери и ребенка г. Усть-Каменогорск»;
Лот № 4 «Поставка и внедрение комплексной медицинской информационной
системы для Городской поликлиники № 11 г.Алматы»;
Лот № 5 «Поставка и внедрение комплексной медицинской информационной
системы для Регионального диагностического центра г.Алматы»;
Лот № 6 «Поставка и внедрение комплексной медицинской информационной
системы для Поликлиники №1 города Костанай»;
Лот № 7 «Поставка и внедрение комплексной медицинской информационной
системы для Центральной районной больницы Жуалинского района
Жамбыльской области»;
Лот № 8 «Поставка и внедрение комплексной медицинской информационной
системы для Городской поликлиники №7 г.Астаны»;
Лот № 9 «Поставка и внедрение комплексной медицинской информационной
системы для Городской больницы №1 г.Астаны»;
Приглашение к участию в торгах
Лот № 10 «Медицинская информационная система для учета доноров и
реципиентов».
Участники имеют возможность подать КП на один или несколько лотов. КП
будут оценены по каждому лоту, с учетом скидок предлагаемых по каждому
лоту или комбинации лотов если применимо. Контракт(ы) будут
присуждены участнику или участникам предлагающим наименьшую
стоимость для Покупателя по комбинированным лотам при условии, что
отобранный
участник
торгов
соответствует
необходимым
квалификационным критериям по лоту или комбинации лотов при
необходимости. Покупатель присудит не более трех лотов одному участнику
торгов, даже если участник торгов предложил наименьшую цену и был
высоко оценен по квалификации.
В случае, если конкурсное предложение одного или нескольких участника
торгов получит наименьшую оцененную стоимость по более чем трем лотам,
критерием выбора лотов для покупателя будет являться наилучшая, с точки
зрения, покупателя комбинация общей стоимости всех присуждаемых лотов
3.
Министерство здравоохранения и социального развития Республики
Казахстан является исполняющим ведомством по данному проекту и настоящим
приглашает правомочных Участников торгов представить в запечатанном виде свои
конкурсные предложения на участие в торгах по проекту по передаче технологий и
проведению институциональной реформы в секторе здравоохранения Республики
Казахстан, а именно поставка, установка, ввод в эксплуатацию медицинских
информационных систем для организаций здравоохранения РК. Период поставки,
установки и ввода в эксплуатацию - 54 недели.
4.
Конкурс будет проводиться с использованием процедуры Международных
конкурсных торгов, изложенной в Руководстве Всемирного банка «Закупки по
займам МБРР и кредитам МАР», изданном в Мае 2004 года, с изменениями от
октября 2006 года и мая 2010 года; он открыт для всех правомочных Участников, в
соответствии с определением этого термина в Руководстве, которые удовлетворяют
перечисленным далее основным минимальным квалификационным критериям
(a)
Участник должен предоставить документальное доказательство
соответствия следующим финансовым требованиям:
-
Средний годовой оборот в долларах США или эквивалент в
течении последних 3 лет (2012, 2013 и 2014 годы):
- не менее US$1,500,000.00 (одного миллиона пятисот тысяч долларов США)
для Лота № 1 «Поставка и внедрение комплексной медицинской
информационной системы для Усть-Каменогорской городской больницы №1»;
- не менее US$1,000,000.00 (одного миллиона долларов США) для Лота № 2
«Поставка и внедрение комплексной медицинской информационной системы
для ГКП на ПХВ «Городская клиническая больница №4» г.Алматы»;
- не менее US$2,000,000.00 (двух миллионов долларов США) для Лота № 3
«Поставка и внедрение комплексной медицинской информационной системы
для Центра матери и ребенка г. Усть-Каменогорск»;
4
Приглашение к участию в торгах
- не менее US$1,000,000.00 (одного миллиона долларов США) для Лота № 4
«Поставка и внедрение комплексной медицинской информационной системы
для Городской поликлиники № 11 г.Алматы»;
- не менее US$1,000,000.00 (одного миллиона долларов США) для Лота № 5
«Поставка и внедрение комплексной медицинской информационной системы
для Регионального диагностического центра г.Алматы»;
- не менее US$1,000,000.00 (одного миллиона долларов США) для Лота № 6
«Поставка и внедрение комплексной медицинской информационной системы
для Поликлиники №1 города Костанай»;
- не менее US$1,000,000.00 (одного миллиона долларов США) для Лота № 7
«Поставка и внедрение комплексной медицинской информационной системы
для Центральной районной больницы Жуалинского района Жамбыльской
области»;
- не менее US$1,000,000.00 (одного миллиона долларов США) для Лота № 8
«Поставка и внедрение комплексной медицинской информационной системы
для Городской поликлиники №7 г.Астаны»;
- не менее US$1,000,000.00 (одного миллиона долларов США) для Лота № 9
«Поставка и внедрение комплексной медицинской информационной системы
для Городской больницы №1 г.Астаны»;
- не менее US$1,500,000.00 (одного миллиона пятисот тысяч долларов США)
для Лота № 10 ««Медицинская информационная система для учета доноров и
реципиентов».
Требования по среднему годовому обороту должны быть применены
последовательно ко всем лотам.
Если Участник является СП, то может быть применена сумма среднего
годового оборота всех участников. Если Участник является СП, то
ответственный партнер должен иметь средний годовой оборот в
эквиваленте не менее половины требуемой суммы за последние 3 года, а
каждый партнера, в размере не менее 10 % от общей потребности.
Участник должен представить аудиторские финансовые ведомости и
баланс
счетов
(или
другие
документы,
предусмотренные
законодательством страны участника торгов) за последние завершенные
3 финансовых года, показывающие устойчивость финансовой позиции
Участника и необходимые ресурсы, которыми он владеет в целях
соответствия требованиям предложенного контракта.
Если участник претендует на присуждение контракта по более чем
одному лоту, тогда он должен продемонстрировать наличие
необходимого среднего годового оборота для соответствия
совокупности квалификационных требований
по индивидуальным
лотам
(b)
Опыт и технические способности
Участник должен предоставить документальное доказательство (включая
информацию о завершенных контрактах и контактной информации заказчиков
которые могут предложить отзывы и которых Покупатель при необходимости
может посетить, чтобы ознакомится с системами, введенными в эксплуатацию
Участником) доказывающее его соответствие следующим требованиям к опыту:
5
Приглашение к участию в торгах
i.
Участник торгов должен функционировать как минимум в течение
последних 5 лет и основной частью его бизнеса должна быть поставка,
разработка и внедрение медицинских информационных систем для
организаций здравоохранения.
ii.
Производители ПО должны иметь как минимум один сертификат из
следующего перечня: Capability Maturity Model Integration (CMMI)
Maturity Level 3, ISO 9000 или СТ РК ИСО 9001:2009, или аналогичных
для процесса управления качеством. (Участник должен предоставить
копию сертификата соответствия, выданного уполномоченным органом).
iii.
Участник должен иметь опыт в обучении конечных пользователей и
специалистов ИТ.
iv.
Участник торгов должен иметь доказанный опыт в создании схожих
проектов: не менее 5 медицинских организаций используют в настоящее
время системы, разработанные или внедренные Участником торгов
(желательно чтобы масштаб данных медицинских организаций
соответствовал Организациям – бенефициариев данного тендера или был
больше). "Доказанный" означает предоставление контактов, адресов,
писем и других документов способных подтвердить использование (и
результаты) Системы, требуемых согласно этого контракта.
Участник торгов должен иметь свою собственную команду с опытом
внедрения похожих проектов. Участник торгов должен предоставить
таблицу со списком сотрудников с указанием их резюме для
доказательства опыта и знаний. Детальные требования к команде
указаны в Разделе VI «Технические требования» пункте R10.4 для лотов
№ 1-9 и R11.4 для лота № 10.. Участник торгов должен предоставить два
набора резюме для того чтобы ему присудили два лота и три набора
резюме чтобы ему присудили три лота
Участник торгов должен представить все документы происхождения для
всех компонентов и продуктов, включая разрешение производителя
использовать продукты для данного контракта или предоставить
подтверждение о наличии прав на продукты (патент, или другие
документы), включая право на Интеллектуальную Собственность и
другие относящиеся права.
Участник торгов (или члены совместного предприятия) должны иметь
доказанный опыт работы с одним или несколькими стандартами,
используемыми в настоящем документе: HL7 v2, v3, FHIR, CDA (R2).
IHE.
v.
vi.
vii.
5.
Заинтересованные правомочные Участники торгов могут получить
дополнительную информацию в Министерстве здравоохранения и
социального развития РК - Департамент инвестицонных проектов и развития
государственного частного партнерства, Группа поддержки реализации
проекта и изучить документацию для торгов по адресу: г. Астана, ул.
Иманова 19, этаж 5, офис 504 в рабочие часы с 09:00-12:30 и 13:30-18:00 с
понедельника по пятницу, кроме официальных праздников.
6.
Полный комплект документации для торгов на английском языке можно
получить при направлении письменного запроса в Группу поддержки
реализации проекта г. Астана, л. Иманова 19, этаж 5, офис 504 в рабочие часы
6
Приглашение к участию в торгах
с 09.00 – 12.30 и 13.30-18.00, с понедельника по пятницу, кроме праздничных
дней. Как альтернатива, комплект документации в форматах PDF и WORD
могут быть направлены заинтересованным Участникам торгов после подачи
письменного заявления в группу поддержки реализации проекта по
электронной почте kazhealth.procurement@gmail.com.
Полный комплект документации для торгов на английском языке в форматах
PDF и Word можно также скачать на сайте проекта healthproject.kz после
прохождения процедуры регистрации.
Разъяснения и поправки к документации для торгов будут также
опубликованы на данном веб-сайте и высланы участникам торгов по
электронной почте.
При появлении разночтений между документами в форматах PDF и Word,
файл PDF будет иметь превалирующее значение.
К тому же заинтересованные участники торгов могут получить полный
комплект документации для торгов на русском языке в формате Word. При
появлении разночтений между английской и русской версией документа,
английская версия будет иметь превалирующее значение.
7.
Конкурсные предложения должны быть доставлены по указанному ниже
адресу не позднее 15 ч. 30 мин 15 октября 2015 года. Предложения должны
сопровождаться залоговым обеспечением в размере:
- 20 000 долларов США для Лота № 1 «Поставка и внедрение комплексной
медицинской информационной системы для Усть-Каменогорской городской
больницы №1»;
- 10 000 долларов США для Лота № 2 «Поставка и внедрение комплексной
медицинской информационной системы для ГКП на ПХВ «Городская
клиническая больница №4» г.Алматы»;
- 30 000 долларов США для Лота № 3 «Поставка и внедрение комплексной
медицинской информационной системы для Центра матери и ребенка г. УстьКаменогорск»;
- 10 000 долларов США для Лота № 4 «Поставка и внедрение комплексной
медицинской информационной системы для Городской поликлиники № 11
г.Алматы»;
- 10 000 долларов США для Лота № 5 «Поставка и внедрение комплексной
медицинской информационной системы для Регионального диагностического
центра г.Алматы»;
- 10 000 долларов США для Лота № 6 «Поставка и внедрение комплексной
медицинской информационной системы для Поликлиники №1 города
Костанай»;
-15000 долларов США для Лота № 7 «Поставка и внедрение комплексной
медицинской информационной системы для Центральной районной больницы
Жуалинского района Жамбыльской области»;
- 10 000 долларов США для Лота № 8 «Поставка и внедрение комплексной
медицинской информационной системы для Городской поликлиники №7
г.Астаны»;
7
Приглашение к участию в торгах
- 10 000 долларов США для Лота № 9 «Поставка и внедрение комплексной
медицинской информационной системы для Городской больницы №1
г.Астаны»;
- 20 000 долларов США для Лота № 10 ««Медицинская информационная
система для учета доноров и реципиентов».
Опоздавшие конкурсные предложения будут отклонены. Конкурсные
предложения будут вскрыты в присутствии представителей Участников
торгов, которые пожелают принять участие в этом мероприятии, по
указанному далее адресу в 15 ч. 30 мин 15 октября 2015 года.
8.
Просим потенциальных Участников торгов обратить внимание на то, что: (i)
в своих предложениях они должны подтвердить, что все программные
продукты либо поставляются на основании действующей лицензии, либо
разработаны самим Участником торгов; и что (ii) нарушения данного
условия квалифицируются как мошенничество, что, грозит запретом на
присуждение контрактов, финансируемых Всемирным банком.
Министерство здравоохранения и социального развития Республики Казахстан
Департамент инвестицонных проектов и развития государственного частного
партнерства,
Группа поддержки реализации проекта
Б. Токежанов–Национальный координатор проекта
010000, Казахстан, г. Астана, ул. Иманова 19, этаж 5, офис 504
Телефон: + 7172 787 235, Факс: + 7172 787 247,
e-mail: kazhealth.procurement@gmail.com
8
Раздел I. Инструкции участникам торгов
9
РАЗДЕЛ I. ИНСТРУКЦИИ УЧАСТНИКАМ ТОРГОВ(ИУТ)
(Одностадийные торги)
Перечень статей
A. Общие положения ..........................................................................................................11
1.
2.
3.
4.
5.
6.
7.
8.
Предмет конкурсных торгов ..................................................................................11
Источник финансирования ....................................................................................11
Мошенничество и коррупция ................................................................................12
Правомочные Участники торгов ...........................................................................15
Приемлемость товаров и услуг ..............................................................................16
Квалификации Участника торгов ..........................................................................17
Стоимость участия в торгах ...................................................................................21
Посещение мест установки информационной системы ......................................21
B. Документация для торгов .............................................................................................22
9.
10.
11.
Содержание Документации для торгов ................................................................22
Разъяснение Документации для торгов и предтендерная конференция ...........23
Внесение поправок в Документацию для торгов ................................................24
C. Подготовка конкурсных предложений ......................................................................24
12.
13.
14.
15.
16.
17.
18.
19.
Язык конкурсного предложения ...........................................................................24
Документы, в составе конкурсного предложения ...............................................24
Цены конкурсных предложений ...........................................................................27
Валюты конкурсного предложения ......................................................................30
Документы, подтверждающие соответствие Информационной системы
требованиям Документации для торгов ...............................................................30
Залоговое обеспечение конкурсного предложения .............................................32
Срок действия конкурсных предложений ............................................................35
Оформление и подписание конкурсного предложения ......................................36
D. Подача конкурсных предложений ..............................................................................37
20.
21.
22.
23.
Опечатывание и маркировка конвертов с конкурсными предложениями ........37
Срок подачи конкурсных предложений ...............................................................37
Опоздавшие конкурсные предложения ................................................................38
Отзыв, замена и модификация конкурсных предложений ................................38
E. Вскрытие и оценка конкурсных предложений ........................................................39
24.
26.
27.
28.
29.
Вскрытие конкурсных предложений Покупателем .............................................39
Предварительное изучение конкурсных предложений .......................................41
Перевод в единую валюту ......................................................................................42
Оценка и сравнение конкурсных предложений ...................................................43
Льготы отечественным Изготовителям ................................................................50
Раздел I. Инструкции участникам торгов
30.
10
Контакты с Покупателем .......................................................................................50
F. Последующий квалификационный отбор и присуждение контракта .................50
31.
32.
33.
34.
35.
36.
37.
38.
Последующий квалификационный отбор ............................................................50
Критерии присуждения Контракта .......................................................................51
Право Покупателя изменить объемы поставок в момент присуждения
Контракта .................................................................................................................51
Право Покупателя принять любое конкурсное предложение и отклонить
любое или все конкурсные предложения .............................................................52
Уведомление о присуждении Контракта ..............................................................52
Подписание Контракта ...........................................................................................53
Залоговое обеспечение выполнения Контракта...................................................53
Третейский судья ....................................................................................................59
Раздел I. Инструкции участникам торгов
11
Инструкции Участникам торгов
A. ОБЩИЕ ПОЛОЖЕНИЯ
1. Предмет
конкурсных
торгов
2. Источник
финансирования
1.1
Покупатель, указанный в ИККП и СУК для Статьи
1.1 (b) (i)ОУК,
или
его
должным
образом
уполномоченный Агент по закупкам, если это
допускается в ИККП (далее взаимозаменяемо
именуемые «Покупатель» в настоящей Документации для
торгов),
приглашает
представить
конкурсные
предложения на поставку и установку Информационной
системы (ИС), кратко описанной в ИККП и более
подробно – в настоящей Документации для торгов.
1.2
Название и идентификационный номер Приглашения к
участию в торгах (ПУТ) и последующего Контракта(ов)
указаны в ИККП.
1.3
В настоящей Документации для торгов термин «в
письменной форме» означает письменное сообщение
(например, по электронной почте, факсу, телексу) с
подтверждением получения, а термин «дни» означает
календарные дни, если иное значение не следует очевидно
из контекста.
1.4
Если указано в ИККП, альтернативные процедуры,
образующие часть или весь процесс того, что обычно
называют Электронными торгами, возможны в той
степени, которая описана или упомянута в ИКПП.
2.1
Заемщик, указанный в ИККП, обратился за получением
или получил заем или кредит (как указано в ИККП,
именуемый в настоящей Документации для торгов
«Заем») от Международного банка реконструкции и
развития или Международной Ассоциации развития
(далее в настоящей Документации для торгов именуемых
«Банк») на сумму, эквивалентную указанной в ИККП в
счет стоимости Проекта, указанного в ИККП. Заемщик
намеревается использовать часть поступлений по этому
Займу на производство правомочных платежей по
Контракту, в целях которого выпущена настоящая
Документация для торгов.
2.2
Банк будет осуществлять платежи только по заявке
Заемщика или его исполняющего ведомства и после
утверждения Банком в соответствии с условиями
Раздел I. Инструкции участникам торгов
12
Соглашения о Займе, причем во всех отношениях они
будут обусловлены положениями и условиями указанного
Соглашения. Соглашение о Займе запрещает снятие
средств с заемного счета в целях платежа какому-либо
физическому или юридическому лицу, или в целях
импорта товаров, если, насколько это известно Банку,
такой платеж или импорт запрещены решением Совета
безопасности ООН, принятым в рамках Главы VII Устава
ООН. Никакая другая сторона, кроме Заемщика, не имеет
никаких прав в рамках Соглашения о Займе и не может
предъявлять претензий на поступления по Займу.
3. Мошенничество 3.1
и коррупция
В соответствии со своей политикой Банк требует, чтобы в
рамках контрактов, финансируемых Банком, заемщики
(включая бенефициаров займов Банка), а также участники
торгов, поставщики, подрядчики и их субподрядчики
соблюдали самые строгие нормы этики в процессе
закупок и выполнения таких контрактов1. В обеспечение
такой политики Банк:
(a)
дает изложенные далее определения следующим
терминам для целей настоящей статьи:
(i)
«коррупция» означает прямое или косвенное
предложение, передачу, получение или
вымогание любой ценности с целью оказать
ненадлежащее влияние на действия другой
стороны;2
(ii)
«мошенничество» означает любое действие
или упущение, включая дезинформацию,
которое умышленно или по неосторожности
вводит в заблуждение или пытается ввести в
заблуждение сторону3 с целью получения
финансовой или другой выгоды или
уклонения от выполнения обязательства;
1
В данном контексте, любое действие, предпринятое участником торгов, поставщиком, подрядчиком
или субподрядчиком с целью оказать влияние на процесс закупки или исполнение контракта для
получения неправомерного преимущества, считается ненадлежащим.
2
Под «другой стороной» понимается должностное лицо, имеющие отношение к процессу закупки или к
исполнению контракта. В данном контексте «должностные лица» включают сотрудников
Всемирного Банка и других организаций, принимающих решения по закупкам, или проверяющих
их.
3
Под «стороной» понимается должностное лицо, понятия «выгода» и «обязательство» применимы к
закупочному процессу или исполнению контракта, а «действие или упущение» направлены на
оказание влияния на закупочный процесс или исполнение контракта.
Раздел I. Инструкции участникам торгов
13
(iii) «сговор» означает договоренность между
двумя или более сторонами имеющую
ненадлежащую цель, включая оказание
влияние на действия другой стороны4;
(iv)
«принуждение»
означает
нанесение
повреждения или ущерба или угроза
нанесения
повреждения
или
ущерба
напрямую или косвенно другой стороне или
собственности другой стороны с целью
оказания
ненадлежащего
влияния
на
5
действия другой стороны;
(v)
«обструкционистская практика» это
(аа)
намеренное
уничтожение,
фальсификация, изменение или сокрытие
подтверждающей
информации
при
проведении расследования или ложное
заявление для того, чтобы фактически
затруднить
расследование
Банка
по
обвинению в коррупции, мошенничестве,
сговоре или насилии и принуждении; и/или
угроза, притеснение или запугивание любой
из сторон, с целью помешать этой стороне
обнародовать известные ей обстоятельства,
относящиеся
к
расследованию,
или
проводить расследование; или
(bb)
действия, направленные на то,
чтобы
фактически
помешать
Банку
воспользоваться
своими
правами
на
проведение
инспекции
и
аудита,
предусмотренных параграфом 3.1 (е),
приведенном далее.
(b)
отклонит предложение о присуждении Контракта,
если придет к выводу о том, что рекомендуемый
для присуждения Контракта Участник торгов, сам
или через своего представителя, был замешан в
коррупции, мошенничестве, сговоре, принуждении
или обструкционизме в процессе конкуренции за
4
Под «сторонами» понимаются участники закупочного процесса (включая должностные лица),
пытающиеся установить цены предложений на искусственном неконкурентном уровне.
5
Под «сторонами» понимаются участники закупочного процесса или исполнения контракта
Раздел I. Инструкции участникам торгов
14
получение данного Контракта;
(c)
аннулирует ту часть займа, которая предназначена
для финансирования контракта, если в какой-либо
момент
времени
будет
установлено,
что
представители Заемщика или бенефициара займа
были замешаны в коррупции, мошенничестве,
сговоре или принуждении в процессе проведения
отбора или выполнения того контракта, а Заемщик
при этом не принял своевременные и надлежащие
меры
по
исправлению
ситуации,
удовлетворительные для Банка;
(d)
наложит на фирму или индивидуала санкции,
включая
объявление
о
лишении,
на
неограниченное время либо на указанный срок,
права на получение финансируемого Банком
контракта, если в какой-либо момент времени
будет установлено, что эта фирма была замешана
напрямую или через посредника в коррупции,
мошенничестве, сговоре, принуждении или
обструкционизме при проведении конкурса или в
процессе выполнения контракта, финансируемого
Банком;и
(e)
будет иметь право потребовать, чтобы в
контракты, финансируемые за счет средств займов
Банка, было включено положение, обязывающее
участников торгов, поставщиков, подрядчиков и
субподрядчиков разрешать Банку проверку их
счетов, учетной и другой документации, связанной
с
подачей
предложений
и
выполнением
контрактов, а также на проведение аудита этих
документов аудиторской фирмой, назначенной
Банком.
3.2
Кроме того, Участники торгов должны быть осведомлены
об условиях, оговоренных в Статье 9.8 и Статье 41.2
Общих условий контракта.
3.3
Любые контакты между Участником торгов и
Покупателем по вопросам заявлений о коррупции или
мошенничестве должны осуществляться в письменной
форме.
3.4
Подписывая Форму Конкурсного предложения, Участник
торгов подтверждает, что он либо является обладателем
Прав интеллектуальной собственности на предлагаемое
Раздел I. Инструкции участникам торгов
15
аппаратное обеспечение, программное обеспечение или
материалы, либо получил от собственника таких прав
соответствующую доверенность и/или лицензию, чтобы
предлагать их. В целях настоящей Статьи, Права
интеллектуальной собственности трактуются согласно
определению в Статье 1.1 (c) (xvii) ОУК. Преднамеренное
искажение таких фактов считается мошенничеством и
подчиняется положениям Статей 3.1 - 3.4 выше, без
ущерба для других мер и средств защиты, к которым
может прибегнуть Покупатель.
4. Правомочные
Участники
торгов
4.1
Государственная принадлежность Участника торгов и
всех сторон, входящих в состав Участника торгов, может
быть любой, с учетом ограничений, изложенных в Разделе
III «Правомочные Страны». Принадлежность Участника к
той или иной стране считается определенной, если
Участник является гражданином этой страны или если
Участник образован, учрежден или зарегистрирован и
действует в соответствии с положениями законов данной
страны.
4.2
Если в отношении Контракта(ов), для которых была
выпущена настоящая Документация для торгов,
проводится
процесс
предварительного
квалификационного отбора, то к участию в торгах
допускаются только те Участники, которые прошли такой
отбор и продолжают отвечать критериям правомочности
согласно настоящей Статье. Прошедшее предварительный
квалификационный отбор совместное предприятие не
может менять состав партнеров или структуру при подаче
конкурсного предложения.
4.3
Фирма может быть не допущена к участию в торгах, если
она:
(a)
привлекалась
Покупателем
для
оказания
консультационных услуг на этапе подготовки
проектной документации, спецификаций или других
документов, подлежащих использованию при
закупке Информационной системы, описанной в
Документации для торгов; или
(b)
является государственным предприятием в стране
Заемщика, за исключением случаев, когда она может
подтвердить, что: (i) обладает юридической и
финансовой самостоятельностью и (ii) действует в
соответствии с торговым правом. Ведомства,
зависящие от Заемщика или Субзаемщика, не
Раздел I. Инструкции участникам торгов
16
допускаются к участию в торгах.
5. Приемлемость
товаров и услуг
4.4
Фирма,
объявленная
Банком
неправомочной
в
соответствии с Руководством Банка «О предотвращении и
борьбе с коррупцией и мошенничеством в проектах,
финансируемых займами МБРР и кредитами МАР» не
может быть правомочна для присуждения контракта.
4.5
Фирма или индивидуал не допускаются или будут
отстранены от участия в торгах, если, в любой момент
времени от публикации объявления о торгах и до
присуждения контракта, эта фирма или индивидуал:
(a)
отстранены Покупателем по согласованию с Банком
в результате исполнения гарантийной декларации в
соответствии со Статьей 17.6 ИУТ по другой
финансируемой Банком закупке, или по другой
причине, согласованной с Банком, или
(b)
признаны Банком неправомочными согласно Статье
3.1 (d) ИУТ. Список индивидуалов и фирм,
отстраненных от участия в проектах Всемирного
Банка
размещен
на
сайте
http://www.worldbank.org/debarr/, или
(с)
находятся под действием санкции наложенной
Советом Безопасности ООН, как оговорено в Статье
2.2 ИУТ.
4.6
Фирма
или
другая
организация,
являющаяся
неправомочной по любому из вышеуказанных условий
данной Статьи, не может участвовать ни как сторона
совместного предприятия, ни как субподрядчик или
поставщик товаров, работ или услуг. Если предложение,
после
исключения
неправомочных
организаций,
становится в существенной степени неполноценным, оно
может быть дисквалифицировано.
4.7
Участники
торгов
должны
предъявить
такое
подтверждение своей продолжающейся правомочности,
удовлетворительное для Покупателя, какое будет
обоснованно затребовано Покупателем.
5.1
В целях настоящей Документации для торгов,
Информационная система означает все перечисленное
ниже:
(a)
необходимые информационные технологии, включая
все аппаратное обеспечение для обработки и
Раздел I. Инструкции участникам торгов
17
передачи информации, программное обеспечение,
запчасти и расходные материалы, которые
Поставщик обязан поставить и установить в рамках
Контракта, плюс вся сопутствующая документация,
а также все иные материалы и товары, подлежащие
поставке, установке, интеграции и вводу в
эксплуатацию (совместно именуемые «Товары» в
отдельных статьях ИУТ); и
(b)
6. Квалификации
Участника
торгов
разработка
соответствующего
программного
обеспечения,
транспортировка,
страхование,
установка,
настройка,
интеграция,
ввод
в
эксплуатацию, обучение, техническая поддержка,
ремонт и техническое обслуживание, а также другие
услуги, необходимые для нормальной эксплуатации
Информационной
системы,
поставляемой
выбранным Участником торгов и в соответствии с
условиями Контракта.
5.2
Средства Займа Банка расходуются только на затраты по
построению Информационной системы из товаров и
услуг, поставляемых сторонами, принадлежащими к
правомочной стране, или произведенных и поставляемых
из правомочных стран-источников, согласно Разделу III
«Правомочные страны». Информационная система
считается произведенной в стране, когда на территории
такой
страны
путем
разработки
программного
обеспечения, изготовления или значительных и важных
работ по сборке или интеграции компонентов получается
коммерчески
признанный
продукт,
существенно
отличающийся по своим базовым характеристикам или
назначению или использованию от своих компонентов.
5.3
В целях настоящей статьи национальная принадлежность
Участника торгов отделяется от страны, где произведена
Информационная система и составляющие ее товары, или
от страны, откуда поставляются сопутствующие услуги.
6.1
Подаваемые Участником торгов в составе своего
конкурсного
предложения
документальные
подтверждения должны удостоверить, к удовлетворению
Покупателя, что:
(a)
Участник
торгов
обладает
финансовыми,
техническими
и
производственными
возможностями, необходимыми для исполнения
Контракта, отвечает квалификационным критериям,
указанным в ИККП, и имеет успешный опыт
Раздел I. Инструкции участникам торгов
18
выполнения аналогичных проектов. Если в
отношении Контракта(ов), в целях которых была
выпущена настоящая Документация для торгов,
проводился
процесс
предварительного
квалификационного отбора, Участник торгов
должен, в качестве составной части своего
конкурсного
предложения,
представить
обновленный
вариант
любых
сведений,
включавшихся
в
Заявку
на
участие
в
предварительном квалификационном отборе;
(В целях установления квалификаций Участника
торгов и если иное не указано в ИККП, опыт и/или
ресурсы любого субподрядчика не учитываются при
оценке квалификаций Участника; учитываются
только опыт и/или ресурсы партнеров по
совместному предприятию.)
(b)
в случае, когда Участник предлагает поставить
ключевые компоненты Информационной системы,
оговоренные в ИККП, изготовителем или
производителем которых он не является, что он
должным образом уполномочен производителем на
поставку таких компонентов в страну Покупателя по
контракту(ам), который может быть заключен по
результатам данных торгов. (Для этого необходимо
представить
в
предложении
Доверенность
изготовителя по форме, приведенной в Разделе VII).
(c)
если Участник торгов предлагает для выполнения
ключевых услуг Субподрядчиков, если и так как
определено в ИККП, эти Субподрядчики
письменно подтвердили согласие выполнять такие
услуг для Участника торгов по контракту(ам),
который может быть заключен по результатам
данных торгов.
(d)
если Участник торгов не ведет хозяйственную
деятельность в стране Покупателя, что Участник
представлен или будет представлен (в случае
присуждения Контракта) в данной стране Агентом,
который
имеет
достаточное
оснащение
и
возможности
для
выполнения
обязательств
Участника торгов по обслуживанию, технической
поддержке, обучению и ремонту, оговоренных в
Общих и Специальных условиях контракта и/или
Технических требованиях.
Раздел I. Инструкции участникам торгов
6.2
6.3
19
Конкурсные предложения, представленные совместными
предприятиями из двух или более фирм-партнеров, также
должны удовлетворять следующим требованиям:
(a)
конкурсное предложение должно быть подписано
так, чтобы оно имело обязательную юридическую
силу для всех партнеров;
(b)
один из партнеров назначается ответственным, и
такое назначение должно быть подтверждено
представлением
доверенности,
подписанной
юридически уполномоченными представителями
всех партнеров;
(c)
ответственный партнер должен быть уполномочен
брать обязательства и получать инструкции для и от
имени любого и всех партнеров по совместному
предприятию, и взаимодействие в рамках полного
исполнения Контракта, включая платежи, должно
поддерживаться исключительно с ответственным
партнером;
(d)
партнер или группа партнеров, ответственные за
определенный компонент(ы) Информационной
системы,
должны
отвечать
минимальным
квалификационным требованиям для данного
компонента;
(e)
фирма может подать предложение от своего имени
или в качестве партнера в одном, и только одном,
совместном предприятии. Если в результате
вскрытия предложений в соответствии со Статьей 24
ИУТ выяснится, что это требование не соблюдается,
все предложения, как от самой этой фирмы, так и от
совместных предприятий, куда она входит, будут
дисквалифицированы.
(f)
все партнеры по совместному предприятию несут
солидарную и индивидуальную ответственность за
исполнение Контракта в соответствии с условиями
Контракта, и такое утверждение должно включаться
в доверенность, указанную в Статье 6.2 (b) ИУТ
выше, в конкурсные предложения и в Контракт (в
случае присуждения Контракта).
Если Участник намеревается передать Субподрядчикам на
исполнение существенные позиции поставок или услуг,
он должен указать в своем предложении наименование и
Раздел I. Инструкции участникам торгов
20
национальную
принадлежность
предполагаемого
субподрядчика по каждой из таких позиций, и должен
нести ответственность за соответствие предлагаемого
субподрядчика требованиям Статьи 4 ИУТ и
представление
соответствующих
подтверждающих
документов, требуемых в Статье 13.1 (e) (iii) ИУТ.
Участники конкурсных торгов могут предлагать более
одного субподрядчика на каждую позицию. При этом
предлагаемые тарифы и цены считаются применимыми к
любому из выбранных субподрядчиков, и никакие
корректировки тарифов и цен не разрешаются.
Покупатель оставляет за собой право исключить любого
субподрядчика из предложенного списка. Это должно
быть сделано до подписания Контракта путем удаления
неприемлемых
субподрядчиков
при
подготовке
Приложения 3 к Контрактному соглашению, в котором
перечисляются одобренные до подписания Контракта
субподрядчики по каждой из позиций. Последующие
дополнения и сокращения данного перечня производятся
в соответствии со Статьей 20 ОУК (с учетом изменений и
дополнений к ней в СУК, если применимо) и
Приложением 3 к Контрактному соглашению.
В целях настоящей Документации для торгов,
Субподрядчиком является любой поставщик товаров или
услуг, с которым Участник торгов заключает контракт на
поставку или выполнение любой части Информационной
системы, поставляемой Участником по Контракту (такой,
как поставка основного аппаратного обеспечения,
программного обеспечения или других компонентов
требуемых Информационных технологий, или оказание
сопутствующих
услуг,
например,
разработка
программного обеспечения, транспортировка, установка,
настройка, интеграция, ввод в эксплуатацию, обучение,
техническая поддержка, обслуживание, ремонт и т.д.).
6.4
Фирма, являющаяся самостоятельным Участником торгов
или партнером по совместному предприятию, не может
быть Субподрядчиком в другом предложении, за
исключением поставки серийно выпускаемого фирмой
оборудования или программного обеспечения, либо
предоставления исключительно сопутствующих услуг,
таких как, монтаж/конфигурирование, рутинное обучение,
текущее обслуживание/поддержка. Если ИККП для
Статьи 6.1 (а) предусматривает принятие во внимание
квалификации Субподрядчика, номинированного на
какие-либо компоненты, при оценке общей квалификации
Раздел I. Инструкции участникам торгов
21
Участника торгов, любой такой номинированный
Субподрядчик лишается права быть самостоятельным
Участником торгов или партнером по совместному
предприятию. То же правило будет применяться и к
фирмам, которые предоставили субподрядные договоры
на отдельные услуги согласно Статье 6.1 (с).
Несоответствие может привести к отклонению всех
предложений, где данная фирма участвует как
самостоятельно, так и в качестве партнера в совместном
предприятии. В случае соответствия данному правилу
или, если фирма не участвует в торгах ни как
самостоятельный Участник, ни как партнер по
совместному предприятию, такая фирма может быть
предложена в качестве субподрядчика в любом числе
предложений. Если ИККП для Статьи 28.1 разрешает
подачу предложений на Подсистемы, лоты или блоки,
условия данной Статьи 6.4 применимо только к
предложениям на одну и ту же Подсистему(ы), лот(ы) или
блок(и).
7. Стоимость
участия в
торгах
7.1
Участник торгов несет все затраты на подготовку и
подачу конкурсного предложения, а Покупатель ни при
каких обстоятельствах не несет обязательств или
ответственности за такие затраты.
8. Посещение мест
установки
информационно
й системы
8.1
Участник торгов может, по желанию, посетить и
осмотреть место или места размещения Информационной
Системы и получить для себя, на свою ответственность и
риск, всю информацию, которая может потребоваться ему
для подготовки конкурсного предложения и заключения
Контракта. Расходы на посещение такой площадки или
площадок Проекта несет Участник торгов.
8.2
Покупатель обеспечивает Участнику торгов или его
сотрудникам или агентам доступ к соответствующей
площадке или площадкам, при условии, что Участник
уведомит Покупателя о предполагаемом визите в
разумные сроки (минимум за четырнадцать (14) дней). В
качестве альтернативы Покупатель может организовать
посещение
площадки
или
площадок
Проекта
одновременно
с
предтендерной
конференцией,
оговоренной в ИККП к Статье 10.2 ИУТ. Непосещение
Участником торгов площадки Проекта не является
причиной для его дисквалификации.
8.3
Посещения
площадки
Проекта
не
должно
организовываться или планироваться после окончания
Раздел I. Инструкции участникам торгов
22
срока подачи конкурсных предложений и до присуждения
Контракта.
B. ДОКУМЕНТАЦИЯ ДЛЯ ТОРГОВ
9. Содержание
Документации
для торгов
9.1
Документация для торгов включает приведенные ниже
разделы и должна изучаться вместе со всеми
дополнениями, выпущенными в соответствии со Статьей
11 ИУТ.
Раздел I
Раздел II
Раздел III
Раздел IV
Раздел V
Раздел VI
Раздел VII
Инструкции Участникам торгов (ИУТ)
Информационная карта конкурсного
предложения (ИККП)
Правомочные страны для поставок товаров,
работ и услуг в рамках закупок,
финансируемых Всемирным банком.
Общие условия контракта (ОУК)
Специальные условия контракта (СУК)
Технические требования (включая График
реализации)
Образцы форм
9.2
Предполагается, что Участники внимательно изучат все
инструкции, формы, термины, спецификации и другую
информацию, включенную в Документацию для торгов.
Неполное представление всех сведений, требуемых в
Документации для торгов, или подача не отвечающего в
достаточной мере любым аспектам указанных требований,
конкурсного предложения является риском для Участника
и может привести к отклонению его конкурсного
предложения.
9.3
Приглашение к участию в торгах не является формально
составной частью Документации для торгов и включено в
нее исключительно для удобства. В случае разночтений
предпочтение отдается собственно Документации для
торгов.
Раздел I. Инструкции участникам торгов
10. Разъяснение
Документации
для торгов и
предтендерная
конференция
23
10.1 Предполагаемый Участник торгов, нуждающийся в какихлибо разъяснениях в отношении Документации для торгов,
может письменно обратиться к Покупателю по адресу
Покупателя и одним из способов, указанных в ИККП.
Также, если Участник сочтет любое из положений
Документации
неприемлемым,
ему
следует
незамедлительно поднять этот вопрос. Покупатель
письменно ответит на любой запрос, связанный с
разъяснением или изменением Документации для торгов,
при условии, что получит запрос не позднее, чем за
двадцать один (21) день до установленного Покупателем
конечного срока подачи конкурсных предложений.
Покупатель рассылает копии своего ответа (включая
описание сути запроса, но без указания на его источник)
всем предполагаемым Участникам торгов, приобретшим
Документацию для торгов у Покупателя.
10.2 Если таковое предусмотрено в ИККП, Покупатель
организует, а Участники могут посетить предтендерную
конференцию, время и место проведения которой указано
в ИККП. Цель конференции состоит в разъяснении
позиций и ответе на вопросы любого характера, которые
могут возникнуть на данном этапе, причем особое
внимание уделяется вопросам к Техническим требованиям.
Участникам предлагается направлять свои вопросы в
письменной форме с тем, чтобы они были получены
Покупателем не позднее, чем за одну неделю до
конференции. Вопросы и ответы передаются в
соответствии со Статьей 10.1 ИУТ. Протокол конференции,
включая заданные вопросы и данные на них ответы ,
наряду с ответами, подготовленными после конференции,
будет без промедления передан всем, кто приобрел
Документацию для торгов у Покупателя. Любое
дополнение включенных в Документацию для торгов
разделов согласно Статье 9.1 ИУТ, необходимость
которого была определена по результатам предтендерной
конференции,
будет
производиться
Покупателем
исключительно в форме Дополнения согласно Статье 11
ИУТ, а не в рамках протокола предтендерной конференции.
Раздел I. Инструкции участникам торгов
24
11.1 В любое время до истечения срока подачи конкурсных
11. Внесение
предложений Покупатель может, по любой причине, по
поправок в
своей собственной инициативе или в ответ на запрос о
Документацию
разъяснении со стороны потенциального Участника торгов,
для торгов
внести изменения в Документацию для торгов. Более
поздние поправки к одним и тем же положениям изменяют
или заменяют собой более ранние.
11.2 Поправки вносятся в форме Дополнений к Документации
для торгов и рассылаются всем перспективным
Участникам, получившим Документацию для торгов от
Покупателя. Дополнения являются обязательными для
Участников
торгов.
Участники
торгов
должны
незамедлительно подтвердить получение любого такого
Дополнения. Предполагается, что конкурсные предложения
Участников будут подготовлены с учетом поправок,
содержащихся в таких Дополнениях.
11.3 Для того, чтобы предоставить Участникам торгов
достаточно времени для учета внесенных поправок при
подготовке своих конкурсных предложений, Покупатель
может, по своему усмотрению, отодвинуть конечный срок
подачи конкурсных предложений, и в этом случае
Покупатель уведомляет Участников торгов о переносе
крайнего срока в письменной форме.
C. ПОДГОТОВКА КОНКУРСНЫХ ПРЕДЛОЖЕНИЙ
12. Язык конкурсного
предложения
12.1 Подготовленное Участником торгов конкурсное
предложение и вся связанная с ним корреспонденция и
документация, которой обмениваются Участник и
Покупатель, должны быть написаны на языке,
указанном в ИККП, или, если это предусмотрено в
ИККП, на одном из двух указанных в ней языков.
Любые печатные издания, включаемые Участником в
свое конкурсное предложение, могут быть на языке, не
предусмотренном в ИККП, при условии, что к ним
прилагается перевод значимых разделов на язык
конкурсного предложения, причем в таких случаях в
целях
толкования
конкурсного
предложения
преимущество будет иметь переводной вариант.
13. Документы, в
составе
конкурсного
13.1 Подаваемое
Участником
торгов
конкурсное
предложение должно включать следующее:
(a)
Форму конкурсного предложения, заполненную и
Раздел I. Инструкции участникам торгов
25
подписанную лицом или лицами, должным
образом
уполномоченными
принимать
обязательства от имени Участника в отношении
Контракта;
предложения
(b)
все Таблицы цен, заполненные в соответствии со
Статьями 14, 15 и 18 ИУТ и подписанные лицом
или лицами, должным образом уполномоченными
принимать обязательства от имени Участника в
отношении Контракта;
(c)
если требуется, гарантийную декларацию или
залоговое обеспечение конкурсного предложения
в соответствии со Статьей 17 ИУТ;
(d)
письменное подтверждение полномочий лица,
подписавшего
конкурсное
предложение,
принимать обязательства от лица Участника
торгов в соответствии со Статьей 19.2 ИУТ;
(e)
приложения:
(i)
Приложение 1: правомочность Участника
торгов
при
отсутствии
предварительного
квалификационного отбора, документы,
удостоверяющие
к
удовлетворению
Покупателя,
правомочность
Участника
торгов
для
подачи
конкурсного
предложения, включая, без ограничений,
документальные подтверждения того, что
Участник
законным
образом
зарегистрирован на территории правомочной
страны согласно Статье 4 ИУТ;
(ii)
Приложение 2: квалификации Участника
торгов
документальные
подтверждения,
свидетельствующие,
к
удовлетворению
Покупателя и в соответствии со Статьей 6
ИУТ,
что
Участник
торгов
имеет
необходимые квалификации для выполнения
Контракта
в
случае
принятия
его
конкурсного
предложения.
В
случае
проведения
предварительного
квалификационного отбора и согласно
Статье 6.1 (a), Участник торгов должен
представить
подтверждения
любых
Раздел I. Инструкции участникам торгов
26
изменений представлявшихся им для
предварительного
квалификационного
отбора сведений или, если таковые
изменения не имели места, соответствующее
заявление об их отсутствии;
любые Доверенности Изготовителя и
субподрядные договоры, указанные в ИККП
к Статьям 6.1 (b) и 6.1 (c) ИУТ;
(iii) Приложение 3: приемлемость товаров и
услуг
документы,
подтверждающие
к
удовлетворению
Покупателя,
что
поставляемые,
устанавливаемые
и/или
реализуемые Участником товары и услуги,
являющиеся
компонентами
Информационной
системы,
являются
приемлемыми товарами и услугами согласно
Статье 5 ИУТ. В случае присуждения
Контракта Участник торгов представляет на
эти компоненты Информационной системы
подтверждение
их
приемлемости,
сопровождаемое
сертификатом
происхождения, выданным в момент
отгрузки;
(iv) Приложение
4:
соответствие
Информационной системы требованиям
Документации для торгов
документальное
подтверждение,
удостоверяющее,
к
удовлетворению
Покупателя и в соответствии со Статьей 16
ИУТ, что поставляемые, устанавливаемые и
реализуемые Участником товары и услуги,
являющиеся
компонентами
Информационной
системы,
отвечают
требованиям Документации для торгов;
(v)
Приложение
5:
предлагаемые
Субподрядчики
перечень всех существенных позиций
товаров или услуг, которые Участник
предполагает приобретать у других сторон
или передавать на субподряд другим
сторонам, с указанием наименования и
национальной
принадлежности
предлагаемых субподрядчиков, включая
Раздел I. Инструкции участникам торгов
27
поставщиков по каждой из этих позиций;
(vi) Приложение
6:
интеллектуальная
собственность, включающее перечни:
(1) всего
программного
обеспечения,
включенного
в
конкурсное
предложение Участника торгов, с
отнесением каждой позиции одной из
категорий программного обеспечения,
описанных в Статье 1.1 (c) ОУК:
(A) Системное, Общего назначения,
Прикладное
программное
обеспечение; и
(B) Стандартное
и
Заказное
программное обеспечение;
(2)
всех Заказных материалов согласно
Статье 1.1(c) ОУК, включенных в
конкурсное предложение Участника.
Все материалы, не отнесенные к Заказным
материалам,
считаются
Стандартными
материалами согласно Статье 1.1(c) ОУК.
Перераспределение
Программного
обеспечения и материалов в другие
категории,
при
необходимости,
производиться в ходе осуществлении
Контракта согласно Статье 39 ОУК
(«Изменения в Системе»).
14. Цены конкурсных
предложений
14.1 Цены на товары и услуги, указанные в Подтаблице цен
на поставку и установку и Подтаблице цен на текущие
расходы в Разделе VII (Формы 2.5 и 2.6), а также
любые другие товары и услуги, предлагаемые
Участником торгов для выполнения требований к
Информационной системе, устанавливаются по
отдельности в формате данных таблиц и суммируются
в соответствующих Сводных таблицах цен в том же
разделе. Цены указываются в соответствии с
инструкциями, изложенными в Разделе VII для разных
таблиц цен, как описано ниже.
14.2 Считается, что цены на позиции, не внесенные
Участником в Таблицы цен в Разделе VII, включены в
цены других позиций. Позиции, вообще не
Раздел I. Инструкции участникам торгов
28
включенные в таблицы цен, считаются исключенными
из конкурсного предложения, и в таком случае, при
условии, что предложение в должной степени отвечает
требованиям, в ходе оценки конкурсного предложения
осуществляется корректировка цены конкурсного
предложения в соответствии со Статьей 28.6 (c) (iii)
ИУТ.
14.3 Уровень детализации цены за единицу должен быть
достаточным для калькуляции стоимости любой
частичной поставки или частичного платежа по
контракту, согласно Графику реализации в Разделе VI,
а также Статье 12 «Условия оплаты» ОУК и СУК. От
Участников может потребоваться представление
разбивки любой составной или паушальной позиции,
включенной в Таблицы цен.
14.4 Цены товаров, являющихся компонентами Системы,
выражаются, определяются и регулируются в
соответствии с правилами, предписанными в издании
ИНКОТЕРМС, указанном в ИККП, и приводятся в
соответствующих колонках таблиц цен в Разделе VII
следующим образом:
(a)
Товары, поставляемые
Покупателя:
из-за
границ
страны
если иное не указано в ИККП, цены указываются
на условиях СИП (с указанием места назначения),
за исключением всех налогов, сборов, пошлин, а
также иных платежей, налагаемых в стране
Покупателя. Место назначения и особые
инструкции для контракта на перевозку
определены в ИККП. При указании цены
Участник вправе выбирать перевозчика из числа
компаний,
зарегистрированных
в
любой
правомочной стране. Аналогично, Участник
может приобретать страховые услуги в любой
правомочной стране-источнике.
(b)
Товары, поставляемые из страны Покупателя:
Цены за единицу товаров, предлагаемых из
страны Покупателя, приводятся на условиях
«франко-завод» («франко-фабрика», «франкопредприятие», «франко-склад» или «с полки»,
если применимо), включая все таможенные
пошлины, налоги, сборы, выплаты, налоги с
продаж и иные налоги и сборы/выплаты,
Раздел I. Инструкции участникам торгов
29
подлежащие уплате за товары до момента их
доставки, но за исключением всех НДС или
налогов с продаж и иных налогов и
сборов/выплат, понесенных за товары на момент
выставления счета или торговой операции, в
случае присуждения Контракта.
(c)
Транспортировка внутри страны:
если иное не предусмотрено в ИККП, стоимость
транспортировки внутри страны, страхования и
сопутствующих местных расходов, связанных с
доставкой товаров на оговоренные площадки
Проекта, указывается отдельно как позиции услуг
согласно Статье 14.5 ИУТ, вне зависимости от
того, поставляются ли товары из-за границы или
из страны Покупателя, за исключением случаев,
когда такие расходы уже включены в цену
товаров, например, когда Статья 14.4 (a) ИУТ
требует условий поставки СИП, а в качестве мест
назначения указаны площадки Проекта.
14.5 Цены на услуги указываются в целом за каждую услугу
(где уместно, с разбивкой на цены за единицу) с
разделением на составляющие цены в местной и
иностранной валютах. Цены включают все и любые
налоги, сборы, пошлины и выплаты, за исключением
только НДС или других косвенных налогов или
гербовых сборов, которые могут налагаться и/или
применяться в стране Покупателя к/на сумму цены
услуг по счету-фактуре, выставляемому Покупателю, в
случае присуждения Контракта. Если иное не указано
в ИККП, цены должны включать все связанные с
оказанием услуг расходы, которые несет Поставщик,
такие как поездки, командировочные расходы,
офисные затраты, связь, перевод, распечатка
материалов и т.д. Затраты, связанные с доставкой услуг
и понесенные Покупателем или его сотрудниками или
третьими сторонами, включаются в цену в пределах,
насколько они напрямую выражены в настоящей
Документации для торгов (например, требование к
Участнику включать расходы на проезд и
проживание/содержание обучаемых сотрудников).
14.6 Цены на текущие расходы, сверх объема, покрытого
гарантией, понесенные в течение Гарантийного
периода, указанного в Статье 29.4 ОУК и цены на
текущие расходы в течение периода послегарантийного
Раздел I. Инструкции участникам торгов
30
обслуживания, определенного в Статье 1.1(e)(xii) СУК,
подробно указываются как цены на услуги согласно
Статье 14.5 ИУТ в Подтаблице цен на текущие расходы
и совокупными итогами в валюте в Сводной таблице
цен на текущие расходы. Текущие расходы включают
все расходы на сопутствующие товары, как то:
запасные
части,
возобновления
лицензий
на
программное обеспечение, оплата труда и т.д.,
необходимые для непрерывной надлежащей работы
Системы, а также, если уместно, расходы Участника на
собственный резерв на случай роста цен.
14.7 Если иное не указано в ИККП, названные Участником
торгов цены остаются фиксированными в течение всего
срока исполнения Контракта Участником и не
подлежат повышению ни при каких обстоятельствах.
Конкурсные
предложения,
допускающие
корректировку цен, будут отклонены.
15. Валюты
конкурсного
предложения
16. Документы,
подтверждающие
соответствие
Информационной
системы
требованиям
Документации для
торгов
15.1 Цены в конкурсном предложении указываются в
следующих валютах:
(a)
Участник может выразить свою цену на все
Информационные технологии, сопутствующие
товары и услуги, поставляемые из-за границ
страны Покупателя, в валютах стран, признанных
правомочными согласно Разделу III. Если
Участник торгов имеет намерение получить
причитающиеся ему платежи в виде сумм в
разных валютах, он должен указать цены за
единицу в соответствующих валютах, однако с
использованием не более трех иностранных
валют.
(b)
Если иное не указано в ИККП, Участник торгов
выражает свои цены на такие Информационные
технологии, сопутствующие товары и услуги,
поставляемые из страны Покупателя (т.е. внутри
такой страны), в валюте страны Покупателя.
16.1 Согласно Статье 13.1(e)(iv), Участник торгов должен
представить, в качестве составной части своего
конкурсного
предложения,
документы,
подтверждающие
соответствие
Информационной
системы, предлагаемой им к поставке и установке по
Контракту, требованиям Документации для торгов.
16.2 Документальное
подтверждение
соответствия
Раздел I. Инструкции участникам торгов
31
Информационной системы требованиям Документации
для торгов представляется в форме письменных
описаний, печатных изданий, диаграмм, сертификатов,
а также отзывов клиентов, включая:
(a)
техническое предложение Участника, а именно
подробное описание предлагаемого технического
решения,
соответствующего
по
всем
существенным
параметрам
Техническим
требованиям (Раздел
VI) и другим частям
Документации для торгов, как в целом, так и по
отдельным
важным
техническим
и
эксплуатационным характеристикам каждого
компонента,
входящего
в
состав
Информационной системы;
(b)
комментарии к каждой позиции Технических
требований
Покупателя,
демонстрирующие
достаточное
соответствие
предлагаемой
Информационной системы таким требованиям.
Для демонстрации соответствия комментарии
должны включать напрямую
выраженные
перекрестные ссылки на соответствующие
страницы
подтверждающих
материалов,
включенных в конкурсное предложение. При
любых
расхождениях
между
такими
постатейными
комментариями
и
любыми
каталогами, техническими спецификациями или
другими
печатными
материалами,
представленными
Участником
торгов,
преимущества
имеют
такие
постатейные
комментарии;
(c)
Предварительный план Проекта описывающий,
помимо иных вопросов, методы, которые
Участник намерен применять для общего
руководства и координации ответственности в
случае присуждения Контракта, а также кадровые
и иные ресурсы, которые он намерен
задействовать. План должен включать подробный
График реализации в форме гистограммы,
показывающий расчетную продолжительность,
последовательность и взаимосвязь всех ключевых
видов деятельности, необходимых для полного
исполнения Контракта. Предварительный план
Проекта также должен отражать иные вопросы,
описанные
в
ИККП.
Кроме
того,
Раздел I. Инструкции участникам торгов
32
Предварительный план Проекта должен отражать
ожидания Участника относительно вклада и
содействия Покупателя и иных сторон в
построении Информационной системы на этапе ее
реализации, а также предлагаемые Участником
способы координации действий всех вовлеченных
сторон;
(d)
письменное подтверждение того, что Участник
торгов принимает на себя ответственность за
успешную интеграцию и взаимодействие всех
компонентов Информационной системы, как того
требует Документация для торгов.
16.3 В целях комментариев, представляемых согласно
Статье 16.2(b) ИУТ, Участник должен учесть, что
ссылки на торговые марки или номера моделей или
национальные или фирменные стандарты, указываемые
Покупателем в Технических требованиях, носят лишь
описательный, а не ограничительный характер. За
исключением прямых запретов на отдельные позиции
или стандарты, приведенных в ИККП, Участник
может предложить в своем конкурсном предложении
альтернативные торговые марки/модели, при условии,
что
он
сумеет
продемонстрировать
удовлетворительным для Покупателя образом, что
такие
замены
в
результате
обеспечат
функционирование Системы, по сути равноценное или
превосходящее то, что указано в Технических
требованиях.
17. Залоговое
обеспечение
конкурсного
предложения
17.1 ИККП к настоящей Статье 17 указывает, требуется ли
обеспечение конкурсного предложения, и, если
требуется, то в форме ли Гарантийной декларации или
Залогового обеспечения. Если Залоговое обеспечение
обязательно или представляется по желанию
Участника, ИККП также указывает его сумму.
17.2 Обеспечение конкурсного предложения оформляется в
целом
в
соответствии
с
образцами
Форм,
представленными в Разделе VII или в иной форме,
одобренной Покупателем до подачи конкурсных
предложений. Обеспечение конкурсного предложения
должно оставаться в силе в течение 28 дней после
истечения срока действия конкурсного предложения, в
т.ч. продленного, если применимо, в соответствии со
Статьей 18.2 ИУТ. В случае использования Залогового
Раздел I. Инструкции участникам торгов
33
обеспечения, оно также должно:
(a)
по усмотрению Участника торгов, иметь форму
удостоверенного
чека,
аккредитива
или
банковской гарантии банковского учреждения,
или поручительства, выданного компаниейгарантом;
(b)
быть выдана авторитетным учреждением по
выбору Участника торгов, расположенным в
правомочной стране; если выдающее учреждение
расположено вне страны Покупателя, то для
признания его залогового обеспечения имеющим
силу у него должно быть финансовое учреждениекорреспондент в стране Покупателя;
(c)
подлежать
оплате
незамедлительно
после
письменного требования Покупателя в случае
наступления
любого
из
обстоятельств,
перечисленных в Статье 17.6 ИУТ;
(d)
подаваться в оригинале; копии не принимаются.
17.3 Гарантийная декларация или Залоговое обеспечение
совместного предприятия должно быть оформлено на
имя совместного предприятия, подающего конкурсное
предложение,
при
условии,
что
совместное
предприятие уже юридически создано, в противном
случае оно должно быть выдано на имя всех партнеров
совместного предприятия, указанных в конкурсном
предложении. Санкции за нарушение условий
Гарантийной декларации согласно Статье 17.6 ИУТ
применяются ко всем партнерам по совместному
предприятию.
17.4 Если в соответствии со Статьей 17.1 ИУТ необходима
Гарантийная декларация или Залоговое обеспечение,
все конкурсные предложения, не включающие в
значительной
мере
приемлемую
Гарантийную
декларацию или Залоговое обеспечение согласно
Статьям 17.2 и 17.3 ИУТ, отклоняются Покупателем
как не отвечающие требованиям Документации для
торгов.
17.5 Срок действия Гарантийных деклараций, если они не
исполнены, истекает, и Залоговые обеспечения, если
они не удержаны согласно Статье 17.6 ИУТ,
Раздел I. Инструкции участникам торгов
34
возвращаются без промедления:
(a)
всем Участникам после отмены конкурсных
торгов согласно Статье 34 ИУТ;
(b)
Участникам, отказавшимся продлить срок
действия своих конкурсных предложений по
просьбе Покупателя в соответствии со Статьей
18.2;
(c)
победившему
Участнику
торгов
после
подписания им Контрактного соглашения и
представления
требуемого
действительного
залогового обеспечения выполнения контракта;
(d)
проигравшим Участникам торгов одновременно с
исполнением
параграфа
(c),
т.е.
после
уведомления их об успешном размещении
контракта у победившего Участника.
17.6 Гарантийная декларация, если таковая имеется, может
быть исполнена или Залоговое обеспечение, если
таковое имеется, может быть удержано:
(a)
если Участник торгов отзывает свое конкурсное
предложение в течение срока его действия,
оговоренного самим Участником в заполненной
им Форме конкурсного предложения, или
продленного срока его действия, на который
Участник согласился в соответствии со Статьей
18.2 ИУТ; или
(b)
если победивший Участник торгов не может:
(i)
подписать Контрактное соглашение
соответствии со Статьей 36 ИУТ; или
в
(ii)
предоставить
залоговое
обеспечение
выполнения Контракта в соответствии со
Статьей 37 ИУТ.
17.7 Если, согласно ИККП, залоговое обеспечение
конкурсного предложения не требуется и:
(a)
если Участник торгов отзывает свое конкурсное
предложение в течение срока его действия,
оговоренного самим Участником в заполненной
им Форме конкурсного предложения, за
исключением случаев предусмотренных Статьей
Раздел I. Инструкции участникам торгов
35
18.2 ИУТ, или
(b)
если победивший Участник не может подписать
контракт как указано в ИУТ 36 или предоставить
залоговое обеспечение выполнения контракта в
соответствии с ИУТ 37.
Заемщик вправе, если это предусмотрено ИУТ,
объявить Участника дисквалифицированным для
присуждения контракта на период, установленный в
ИУТ.
18. Срок действия
конкурсных
предложений
18.1 Конкурсные предложения остаются в силе, как
минимум, в течение оговоренного в ИККП периода
после
конечного
срока
подачи
конкурсных
предложений, указанного Покупателем в Статье 21
ИУТ. Предложение, имеющее более короткий период
действия, будет отклонено Покупателем как не
отвечающее условиям Документации для торгов. Для
удобства Участников торгов в ИККП указан
минимальный
первоначальный
срок
действия
конкурсных предложений, если применимо, согласно
Статье 17.1 ИУТ для целей их обеспечения. Однако,
Участники торгов должны скорректировать даты,
указанные в ИККП, с учетом любых переносов
конечного срока подачи конкурсных предложений
согласно Статье 21.2 ИУТ.
18.2 При исключительных обстоятельствах, до истечения
срока действия конкурсных предложений, Покупатель
может обратиться к Участникам торгов с просьбой о
продлении срока действия их предложений. Такая
просьба и ответы на нее оформляются письменно.
Участник торгов вправе отклонить такую просьбу без
риска исполнения его Гарантийной декларации или
удержания его Залогового обеспечения, однако в этом
случае его конкурсное предложение не принимает
дальнейшего участия в конкурсе и не может
претендовать на присуждение Контракта. За
исключением случая, оговоренного в Статье 18.3 ИУТ,
Участнику торгов, удовлетворившему такую просьбу,
не будет вменено в обязанность или разрешено вносить
изменения в его конкурсное предложение, однако он
должен будет продлить действие обеспечения своего
предложения на соответствующий период.
18.3 Если, в случае контрактов с твердой ценой,
присуждение Контракта задерживается на период,
Раздел I. Инструкции участникам торгов
36
превышающий пятьдесят шесть (56) дней после
истечения первоначального срока действия конкурсных
предложений,
цена
контракта
должна
быть
скорректирована на условиях, указанных в просьбе о
продлении такого срока. Оценка предложений
осуществляется на основании цен конкурсного
предложения без учета указанной выше корректировки.
19. Оформление и
подписание
конкурсного
предложения
19.1 Участник торгов должен подготовить оригинал
комплекта документов, составляющих конкурсное
предложение, четко указав на нем «ОРИГИНАЛ», а
также оговоренное в ИККП количество комплектовкопий конкурсного предложения, указав на них
«КОПИЯ №1», «КОПИЯ №2» и т.д., сколько
применимо. В случае расхождения между оригиналом
и копиями, преимущество имеет оригинал.
19.2 Оригинал и все копии конкурсного предложения
(включающие комплект перечисленных в Статье 13.1
ИУТ документов) должны быть отпечатаны или
написаны несмываемыми чернилами и подписаны
лицом
или
лицами,
должным
образом
уполномоченными подписываться от имени Участника.
Такой уполномочивающий документ должен быть
оформлен в письменном виде и включен в комплект
конкурсного предложения согласно Статье 13.1(d)
ИУТ.
Имя
и
должность
каждого
лица,
подписывающего такой уполномочивающий документ,
должны быть напечатаны под их подписями. Все
страницы конкурсного предложения, за исключением
неизмененных печатных изданий, должны быть
парафированы лицом или лицами, подписывающими
конкурсное предложение.
19.3 Конкурсное предложение не должно содержать
никаких вставок между строками, подтирок или
надписей поверх затертого текста, за исключением
исправлений ошибок, допущенных Участником торгов,
причем в таких случаях такие исправления должны
быть
парафированы
лицом
или
лицами,
подписывающими конкурсное предложение.
19.4 В Форме конкурсного предложения (образец которой
представлен в Разделе «Образцы форм» Документации
для торгов) Участник должен сообщить сведения,
касающиеся
выплаты
комиссионных
или
вознаграждений,
если
таковые
имели
место,
Раздел I. Инструкции участникам торгов
37
выплаченных или подлежащих выплате агентам в связи
с данной закупкой и исполнением Контракта в случае
его присуждения Участнику.
D. ПОДАЧА КОНКУРСНЫХ ПРЕДЛОЖЕНИЙ
20. Опечатывание
и маркировка
конвертов с
конкурсными
предложениями
20.1 Участник торгов помещает оригинал конкурсного
предложения и каждую из его копий в отдельный конверт,
запечатывает их, пометив, соответственно, «ОРИГИНАЛ»
и «КОПИЯ № [номер]». Затем все эти конверты
помещаются в один общий внешний конверт.
20.2 На внутренних и наружном конвертах следует:
(a)
указать адрес (указанный в ИККП) и наименование
Покупателя в качестве адресата; и
(b)
указать наименование Займа/Проекта согласно
ИККП к Статье 2.1 ИУТ, наименование и номер
Приглашения к участию в торгах, и наименование
Контракта(ов) согласно ИККП к Статье 1.2, а также
предупреждение «НЕ ВСКРЫВАТЬ ДО [время и
дата]» с указанием часа и даты, оговоренных в
ИККП к Статье 24.1 ИУТ.
20.3 На внутренних конвертах также следует указать
наименование и адрес Участника торгов, чтобы
предложение можно было возвратить невскрытым в
случае признания его «опоздавшим».
20.4 Если внешний конверт не запечатан и не помечен в
соответствии с требованиями Статьи 20.2 ИУТ выше,
Покупатель не несет никакой ответственности за потерю
или
преждевременное
вскрытие
конкурсного
предложения. Если внешний конверт содержит указание
на Участника торгов, Покупатель не может гарантировать
анонимность подачи предложения, однако такое указание
не является причиной для отклонения конкурсного
предложения.
21. Срок подачи
конкурсных
предложений
21.1 Конкурсные предложения должны быть получены
Покупателем по адресу, указанному в ИККП к Статье 20.2
ИУТ, не позднее часа и даты, указанных в ИККП.
21.2 Покупатель может, по своему усмотрению, отодвинуть
конечный срок подачи конкурсных предложений на более
поздний срок, внеся поправки в Документацию для торгов
Раздел I. Инструкции участникам торгов
38
в соответствии со Статьей 11.3 ИУТ, причем в этом
случае срок действия всех прав и обязанностей
Покупателя и Участников торгов продлеваются с учетом
измененного конечного срока.
22. Опоздавшие
конкурсные
предложения
22.1 Любое
конкурсное
предложение,
полученное
Покупателем после истечения конечного срока,
установленного для подачи конкурсных предложений в
ИККП к Статье 21 ИУТ, отклоняются и возвращаются
Участнику торгов невскрытыми.
23. Отзыв, замена и 23.1 Участник торгов может отозвать, заменить или изменить
свое предложение после его подачи, при условии, что
модификация
письменное уведомление об отзыве, замене или
конкурсных
изменении получено Покупателем до истечения крайнего
предложений
срока подачи конкурсных предложений. Все уведомления
должны
быть
должным
образом
подписаны
уполномоченным представителем и должны включать
копию авторизации (доверенность) в соответствии со
Статьей 19.2 ИУТ.
23.2 Уведомления об отзыве, замене или изменении должны:
(a)
быть адресованы Покупателю по адресу, указанному
в ИККП для Статьи 20.2 (a) ИУТ, и
(b)
иметь обозначение наименования Контракта,
название ПУТ и его номер, а также слова
«Уведомление
об
отзыве
конкурсного
предложения», «Уведомление о замене конкурсного
предложения» или «Уведомление об изменении
конкурсного предложения».
23.3 Уведомление может также быть отправлено с помощью
электронных средств связи, таких как, факсимиле или
электронная почта, но в этом случае должны включать
также скан почтовой квитанции с адресами отправителя и
получателя бумажной версии уведомления, а также скан
доверенности.
23.4 Предложения, которые были отозваны в соответствии со
Статьей 23.1, должны быть возвращены Участникам
невскрытыми. Уведомления об отзыве конкурсных
предложений, полученные после крайнего срока подачи
конкурсных предложений будут проигнорированы, а
поступившее предложение будет рассматриваться как
действительно поданное предложение.
Раздел I. Инструкции участникам торгов
39
23.5 Замена или изменение конкурсного предложения должно
быть подготовлено, запечатано, промаркировано и
отправлено следующим образом:
(a)
Участники торгов должны подготовить оригинал, а
также количество копий, указанное в ИККП для
Статьи 19.1 ИУТ для любой замены или изменения
своего предложения, четко указав на двух
внутренних конвертах «ЗАМЕНА ПРЕДЛОЖЕНИЯ
–
ОРИГИНАЛ»
или
«ИЗМЕНЕНИЕ
ПРЕДЛОЖЕНИЯ – ОРИГИНАЛ», а также
«ЗАМЕНА ПРЕДЛОЖЕНИЯ – КОПИИ» и
«ИЗМЕНЕНИЕ ПРЕДЛОЖЕНИЯ – КОПИИ».
Внутренние конверты должны быть запечатаны во
внешний конверт, который должен иметь четкую
надпись
«ЗАМЕНА
ПРЕДЛОЖЕНИЯ»
или
«ИЗМЕНЕНИЕ ПРЕДЛОЖЕНИЯ».
(b)
Прочие условия, относящиеся к маркировке и
отправке замены и изменения предложения должны
соответствовать Статьям 20.2, 20.3 и 20.4 ИУТ.
23.6 Конкурсное предложение не может быть отозвано,
заменено или изменено в промежутке между крайним
сроком подачи предложений и истечением срока действия
конкурсных предложений, указанного Участником торгов
в Форме подачи конкурсного предложения, или срока
продления такового, с которым согласился Участник.
Отзыв предложения в этом интервале может привести к
исполнению Гарантийной Декларации, если таковая
предусмотрена, или к изъятию Залогового обеспечения
конкурсного предложения, если таковая предусмотрена, в
соответствии со Статьей 17.6 ИУТ.
E. ВСКРЫТИЕ И ОЦЕНКА КОНКУРСНЫХ ПРЕДЛОЖЕНИЙ
24. Вскрытие
конкурсных
предложений
Покупателем
24.1 Покупатель вскрывает все конкурсные предложения,
включая отзывы, замены и изменения, публично, в
присутствии представителей Участников, пожелавших
посетить это мероприятие, по адресу, в день и час,
указанные в ИККП. Представители Участников в
подтверждение своего присутствия расписываются в
списке присутствовавших.
24.2 Первыми вскрываются и зачитываются вслух конверты,
помеченные
как
«ОТЗЫВ
КОНКУРСНОГО
Раздел I. Инструкции участникам торгов
40
ПРЕДЛОЖЕНИЯ» и конверты с соответствующими
предложениями не вскрываются и возвращаются
Участникам торгов. Отзыв предложения недопустим в
случае отсутствия действующей доверенности на такой
отзыв, или, если он не был зачитан на вскрытии. Затем
вскрываются и зачитываются конверты, обозначенные
«ЗАМЕНА КОНКУРСНОГО ПРЕДЛОЖЕНИЯ», и
производится замена соответствующих предложений на
вскрытые, причем заменяемые предложения не
вскрываются и возвращаются Участникам торгов.
Замена предложения недопустима в случае отсутствия
действующей доверенности на такую замену, или, если
она не была зачитана на вскрытии. Конверты с
надписью
«ИЗМЕНЕНИЕ
КОНКУРСНОГО
ПРЕДЛОЖЕНИЯ» должны вскрываться и зачитываться
вместе с соответствующими предложениями. Изменение
предложения недопустимо в случае отсутствия
действующей доверенности на такое изменение, или,
если оно не было зачитано на вскрытии. Только
предложения, открытые и зачитанные на вскрытии,
могут направляться на дальнейшее рассмотрение.
24.3 Конкурсные предложения вскрываются по одному с
оглашением следующей информации: наименование
Участника торгов; наличие или отсутствие изменений;
итоговая цена конкурсного предложения, включая
любые безусловные скидки и, если применимо, цены и
безусловные скидки на Подсистемы, лоты или части;
наличие или отсутствие Гарантийной декларации или
Залогового обеспечения, если они требуются; условные
скидки, предлагаемые за присуждение более одной
Подсистемы, лота или части, если ИККП к Статье 28.1
ИУТ допускает рассмотрение таких скидок при оценке
конкурсных предложений; любые другие сведения,
которые Покупатель сочтет уместными.
24.4 При дальнейшей оценке рассматриваются только те
конкурсные предложения и изменения, которые были
вскрыты и оглашены в ходе вскрытия конкурсных
предложений, независимо от обстоятельств. Невскрытые
и неоглашенные конкурсные предложения, а также
предложения, должным образом отозванные согласно
Статье 24.2 ИУТ, будут незамедлительно возвращены
подавшим их Участникам невскрытыми.
24.5 Покупатель готовит протокол вскрытия конкурсных
предложений, который должен включать информацию,
Раздел I. Инструкции участникам торгов
41
оглашенную для присутствовавших при вскрытии
согласно Статье 24.3 ИУТ. Протоколы незамедлительно
рассылаются всем Участникам торгов, подавшим свои
конкурсные предложения до наступления конечного
срока их подачи.
25. Разъяснение
конкурсного
предложения
25.1 В ходе оценки Конкурсных предложений Покупатель
может, по своему усмотрению, обратиться к Участнику
с просьбой о разъяснении его конкурсного предложения.
Просьба Покупателя о разъяснении и ответ на нее
должны подаваться в письменном виде, и при этом не
должно поступать никаких просьб, предложений или
разрешений на изменение цены или сути конкурсного
предложения.
26. Предварительное
изучение
конкурсных
предложений
26.1 Покупатель изучает конкурсные предложения на
предмет их полноты, наличия ошибок в расчетах,
требуемых поручительств, правильности подписания
документов, общего порядка оформления предложений.
В
случае
если
проводился
предварительный
квалификационный отбор в целях Контакта(ов), для
которых выпущена настоящая Документация для торгов,
Покупатель должен убедиться, что все конкурсные
предложения
поступили
от
прошедших
предварительный квалификационный отбор Участников,
а в случае совместных предприятий – что партнеры и
структура совместного предприятия не претерпели
изменений с момента такого отбора.
26.2 Арифметические ошибки исправляются следующим
образом. При наличии расхождений между ценой за
единицу и итоговой ценой, получаемой путем
умножения цены за единицу на количество, или между
прибавляемыми или вычитаемыми промежуточными
итогами и окончательным итогом, преимущественное
значение имеют цена за единицу или промежуточные
итоги, а окончательная итоговая цена подлежит
корректировке, за исключением случаев, когда, по
мнению Покупателя, имеет место очевидно ошибочная
постановка запятой перед десятичными знаками в цене
за единицу или промежуточном итоге, и в таких случаях
преимущественное
значение
имеет
указанный
окончательный итог за позицию, а цена за единицу или
промежуточный итог подлежат корректировке. При
наличии расхождений между словами и цифрами,
сумма,
выраженная
словами,
будет
иметь
преимущественное значение, за исключением случаев,
Раздел I. Инструкции участникам торгов
42
когда такое расхождение имеет место в результате
опечатки, и для Покупателя совершенно очевидно, как
исправить такую опечатку. Если Участник торгов, чье
предложение было признано имеющим наименьшую
оценочную стоимость, не принимает исправления
ошибок, его предложение отклоняется.
26.3 Покупатель может не принимать во внимание
незначительные отступления от формы, несоответствия
или неточности в конкурсном предложении, которые не
представляют собой существенных отклонений, при
условии, что такое непринятие во внимание не повредит
и не ущемит конкурсный рейтинг любого из
Участников.
26.4 Перед детальной оценкой Покупатель определяет
приемлемость качества, полноту и степень соответствия
Документации для торгов каждого предложения. В
целях такого определения, в достаточной степени
отвечающим требованиям считается предложение,
соответствующее всем условиям, положениям и
спецификациям Документации для торгов, без
существенных отклонений, исключений, возражений,
условностей или оговорок. Существенными считаются
отклонения, исключения, условности или оговорки,
которые:
(i)
любым
существенным
образом
ограничивают состав, качество или эксплуатационные
характеристики Информационной системы; или (ii)
ограничивает
любым
существенным
образом,
противоречащим Документации для торгов, права
Покупателя или обязательства победителя торгов по
Контракту; или (iii) принятие которых может
несправедливо повлиять на конкурентное положение
других
Участников,
подавших
конкурсные
предложения, в достаточной степени отвечающие
требованиям.
26.5 Если конкурсное предложение не отвечает в
достаточной степени требованиям Документации для
торгов, оно отклоняется Покупателем, и представивший
его Участник не может в дальнейшем привести его в
соответствие требованиям путем внесения исправлений.
Решение Покупателя о соответствии конкурсного
предложения принимается исходя из содержания самого
предложения.
27. Перевод в
27.1 В
целях
оценки
и
сопоставления
конкурсных
Раздел I. Инструкции участникам торгов
единую валюту
28. Оценка и
сравнение
конкурсных
предложений
43
предложений Покупатель переводит все цены
конкурсных предложений, выраженные в разных
валютах, в единую валюту, указанную в ИККП, с
применением обменного курса продажи, установленного
источником, указанным в ИККП, на дату, также
указанную в ИККП.
28.1 Покупатель
оценит
и
сопоставит
конкурсные
предложения, признанные в достаточной мере
отвечающими условиям Документации для торгов
согласно Статье 26 ИУТ. Оценка производится исходя
из следующих допущений:
(a)
Контракт будет присужден Участнику, чье
конкурсное предложение будет иметь наименьшую
оценочную стоимость для Информационной
системы в целом; или
(b)
если определено в ИККП, Контракты на каждую
отдельную Подсистему, лот или часть, указанные в
Технических требованиях, будут присуждены
Участникам, в чьи конкурсные предложения в
результате будут представлять наименьшую
совокупную оценочную стоимость за Систему в
целом.
В последнем случае в конкурсных предложениях могут
предлагаться условные скидки за присуждение более
чем одной Подсистемы, лота или части. Однако такие
скидки будут приниматься во внимание при оценке
цены, только если это подтверждено в ИККП.
28.2 На предмет присуждения Контракта рассматриваются
конкурсные предложения:
(a)
подробная оценка которых, с использованием
указанных в Статьях 26.3 и 26.4 ИУТ стандартов
соответствия, подтверждает, что они отвечают
коммерческим и техническим требованиям, и
включают аппаратное и программное обеспечение,
сопутствующее
оборудование,
продукты,
материалы и иные товары и услуги, являющиеся
компонентами
Информационной
системы,
практически полностью в нужных количествах для
Информационной системы в целом или, если
допускается в ИККП к Статье 28.1 ИУТ, для
отдельной Подсистемы, лота или части, и
Раздел I. Инструкции участникам торгов
(b)
44
которые предлагают Информационные технологии,
пригодность которых для работы по стандартам,
заявленным
в
конкурсном
предложении,
подтверждена
путем
прохождения
эксплуатационных испытаний, эталонного теста
и/или функционального теста, которые может
потребовать Покупатель согласно Статье 31.2 ИУТ.
28.3 Покупатель оценивает конкурсные предложения на
основе цен, указанных в соответствии со Статьей 14
ИУТ («Цены конкурсного предложения»).
28.4 Если разрешено в ИККП, при оценке отвечающих
требованиям конкурсных предложений Покупатель
будет принимать в расчет технические факторы в
дополнение к ценовым факторам. Для каждого
отвечающего требованиям предложения рассчитывается
Оценочная стоимость конкурсного предложения (B) по
приведенной ниже формуле, которая позволяет
произвести
всестороннюю
оценкуценыкаждого
конкурсногопредложенияиеготехническихдостоинств:
B
Clow
T
1  X 
X 
C
Thigh
где:
C
= Оценочная
предложения
стоимость
конкурсного
Clow = наименьшая из всех Оценочных стоимостей
среди отвечающих требованиям конкурсных
предложений
T
= итоговая Техническая
предложения
оценка
конкурсного
Thigh = Техническая оценка конкурсного предложения,
получившего наивысшие баллы среди всех
отвечающих требованиям предложений
X
= вес цены согласно ИККП
Предложение с наивысшей Расчетной оценкой
конкурсного предложения (B) среди отвечающих
требованиям предложений называется предложением с
наименьшей оценочной стоимостью и является
приемлемым для присуждения Контракта при условии,
что
Участник
прошел
предварительный
Раздел I. Инструкции участникам торгов
45
квалификационный отбор и/или сочтен достаточно
квалифицированным для выполнения Контракта в
соответствии со Статьей 31 ИУТ («Последующий
квалификационный отбор»).
28.5 Если в дополнение к ценовым факторам Покупатель
счел необходимым придать вес важным техническим
факторам (т.е. вес цены Х при оценке будет считаться
меньше единицы), которые не могут быть сведены к
стоимости жизненного цикла или критерию «да»/«нет»,
общая сумма технических баллов, присужденная
каждому предложению по формуле оценки будет
определяться путем прибавления и взвешивания оценок,
выставленных оценочной комиссией за технические
параметры в соответствии с изложенными ниже
критериями:
(a)
оцениваемые технические параметры в общих
чертах указаны ниже и специально обозначены в
ИККП:
(i)
параметры производительности, мощности
или
функциональности,
которые
или
превосходят уровни, заданные в качестве
обязательных в Технических требованиях,
и/или влияют на стоимость жизненного
цикла или эффективность Информационной
системы;
(ii)
эксплуатационные свойства, такие как
удобство
использования,
удобство
администрирования, легкость расширения,
которые влияют на стоимость жизненного
цикла и эффективность Информационной
системы;
(iii) качество Предварительного плана Проекта
Участника, подтверждаемое тщательностью,
обоснованностью и соответствием: (a)
графиков задач и ресурсов, как общих, так и
специальных,
и
(b)
предлагаемых
мероприятий по управлению и координации,
обучению,
обеспечению
качества,
технической
поддержке,
логистике,
разрешению проблем и передаче знаний, а
также
остальных
видов
деятельности,
определенных Покупателем в Разделе
VI(«Технические
требования»)
или
Раздел I. Инструкции участникам торгов
46
предлагаемых Участником торгов исходя из
имеющегося у Участника опыта;
(b)
оценки за каждый из технических параметров
будут сгруппированы в несколько оценочных
категорий, которые в общих чертах указаны ниже и
специально обозначены в ИККП, а именно:
(i)
технические параметры, отражающие степень
соответствия
Информационной
системы
рабочим задачам Покупателя (включая
обеспечение
качества
и
меры
по
предотвращению
рисков,
связанных
с
построением Информационной системы);
(ii)
технические параметры, отражающие степень
соответствия
Информационной
системы
стандартам
качества
функционирования
Системы;
(iii) технические параметры, отражающие степень
соответствия
Информационной
системы
Общим
техническим
требованиям
к
аппаратному
обеспечению,
сети
и
коммуникациям, Программному обеспечению
и услугам;
(c)
как указано в ИККП, для каждой из категорий
будет задан вес, а внутри каждой категории
каждый параметр также получит свой вес.
(d)
при проведении оценки, оценочная комиссия
присуждает
каждому
желательному/предпочтительному
параметру
целое число баллов от 0 до 4, где 0 обозначает
отсутствие параметра, а баллы от 1 до 4 отражают
предварительно
определенную
стоимость
желательных
параметров,
поддающихся
объективному
ранжированию
(например,
дополнительная
память,
дополнительные
запоминающие емкости большого размера и т.д.,
если такие дополнительные
увеличения
благоприятно сказываются на работе системы) или
если
параметр
отражает
желательную
функциональность (например, пакет программ) или
качество, улучшающие перспективы успешного
внедрения
(например,
сильные
стороны
предлагаемого
кадрового
состава
Проекта,
Раздел I. Инструкции участникам торгов
47
методологии, проработанный План Проекта,
указанные в конкурсном предложении). При этом 1
будет означать, что данный параметр присутствует,
но с недостатками, 2 балла выставляются за
соответствие требованиям, 3 балла – за
незначительное превышение требований и 4 – за
существенное превышение требований;
(e)
оценки за каждый из параметров (i) внутри
категории (j) суммируются с оценками других
параметров внутри этой же категории с
получением в результате взвешенной суммы,
составляющая Техническую оценку категории, по
следующей формуле:
k
S j   t ji  w ji
i 1
где:
tji
=
Техническая оценка параметра «i» в
категории «j»
wji = вес параметра «i» в категории «j»
k
= количество оцениваемых параметров в
категории «j»
k
w
и
i 1
(f)
ji
1
Технические оценки по категориям суммируются, и
получаемая в результате взвешенная сумма
показывает
итоговую
Техническуюоценкуконкурсногопредложенияпосл
едующейформуле:
n
T   S j Wj
j 1
где:
Sj
= Техническая оценка категории «j»
Wj = вес категории «j» согласно ИККП
n
= количество категорий
n
и Wj  1
j 1
28.6 Оценочная стоимость конкурсного предложения (C) для
каждого отвечающего требованиям предложения
определяется как сумма скорректированной цены
Поставки и Монтажа (P) и Текущих расходов (R);
Раздел I. Инструкции участникам торгов
48
где скорректированная цена Поставки и Монтажа (P)
определяется как:
(a)
цена аппаратного и Программного обеспечения,
сопутствующего
оборудования, продуктов,
Материалов и других Товаров, предлагаемых к
поставке внутри или из-за границ страны
Покупателя в соответствии со Статьей 14.4 ИУТ;
плюс
(b)
итоговая цена за всю разработку программного
обеспечения,
транспортировку,
страхование,
установку, настройку, интеграцию, Ввод в
эксплуатацию, испытания, обучение, техническую
поддержку, ремонт и другие Услуги согласно
Статье 14.5 ИУТ
(c)
с корректировкой с учетом:
(i)
предлагаемых отклонений от Графика
реализации, представленного в Технических
требованиях, ведущих к просрочке сроков
построения Информационной системы в
целом, если они разрешены в ИККП и при
условии, что они не превышают максимально
допустимых
сроков
просрочки,
определенных в ИККП. В целях оценки
производится пропорциональное увеличение
итоговой цены Поставки и Монтажа с
использованием
процентной
ставки(ок),
указанных в ИККП, за каждую неделю
просрочки.
Конкурсные
предложения,
предлагающие поставки с просрочкой,
превышающей максимально допустимую,
могут быть отклонены;
(ii)
отклонений
от
графика
платежей,
предусмотренного в СУК. Если такие
отклонения разрешены в ИККП, с целью
оценки общая цена Поставки и Монтажа
увеличивается пропорционально на сумму
процентного дохода, который мог бы быть
получен на сумму любых платежей,
осуществление которых в предлагаемом
графике намечено раньше, чем в графике
СУК, по процентной ставке, указанной в
ИККП;
Раздел I. Инструкции участникам торгов
49
(iii) товаров
и
услуг,
необходимых
для
Информационной системы, но не указанных в
предложении
или
необходимых
для
исправления несущественных отклонений
предложения, добавляемых к итоговой цене
Поставки и Монтажа с использованием
стоимости, основанной на самой высокой
цене на аналогичные товары и услуги,
приведенной
в
других
конкурсных
предложениях, или, при отсутствии такой
информации, их стоимость будут рассчитана
исходя из доминирующих прейскурантных
цен. Если недостающие товары и услуги
относятся к оцениваемым техническим
параметрам, то соответствующая оценка за
параметр равна нулю;
(iv) исправлений арифметических ошибок
соответствии со Статьей 26.2 ИУТ;
(v)
(d)
в
любых скидок, предлагаемых за присуждение
более одной Подсистемы, лота или части,
если ИККП к Статье 28.1 ИУТ разрешает учет
скидок при оценке цены.
Текущие расходы (R) сводятся к чистой
дисконтированной стоимости и определяются по
следующей формуле:
NM R
x
R 
x
x  1 1  I 
где
N = количество лет в Гарантийном периоде
согласно Статье 29.4 СУК
M = количество
лет
в
периоде
послегарантийного обслуживания согласно
Статье 1.1(e)(xii) СУК
x = индекс 1, 2, 3, ... N + M, представляющий
каждый
год
совокупного
периода
гарантийного
и
послегарантийного
обслуживания.
Rx = итоговая сумма Текущих расходов за год
«x», указанная в Подтаблице текущих
расходов
I = ставка дисконтирования, применяемая для
вычисления
чистой
дисконтированной
Раздел I. Инструкции участникам торгов
50
стоимости в соответствии с ИККП.
29. Льготы
отечественным
Изготовителям
29.1 Льготы местным Участникам торгов не применяются.
30. Контакты с
Покупателем
30.1 Если Участник торгов пожелает связаться с
Покупателем по любым вопросам, касающимся
конкурсного предложения, в период с момента вскрытия
конкурсных предложений до присуждения Контракта,
он должен сделать это в письменном виде.
30.2 Если Участник торгов пытается напрямую повлиять на
Покупателя или иным образом вмешаться в процесс
оценки конкурсных предложений и принятия решения о
присуждении Контракта, его предложение будет
отклонено.
F. ПОСЛЕДУЮЩИЙ КВАЛИФИКАЦИОННЫЙ ОТБОР И
ПРИСУЖДЕНИЕ КОНТРАКТА
31. Последующий
квалификационный
отбор
31.1 Покупатель определяет, за свой счет и к своему
удовлетворению, является ли Участник (включая
партнеров по совместному предприятию и любых
субподрядчиков, квалификации которых ИККП к
Статье
6.1
разрешает
рассматривать
при
определении
квалификаций
Участника),
чье
предложение имеет наименьшую оценочную
стоимость, достаточно квалифицированным для
удовлетворительного выполнения Контракта в
соответствии со Статьей 6 ИУТ. Если в отношении
Контракта(ов), для которого выпущена настоящая
Документация
для
торгов,
проводился
предварительный
квалификационный
отбор,
Покупатель определяет описанным выше образом,
что с момента предварительного отбора не
произошло существенных изменений, негативно
влияющих
на
способность
Участника,
представившего предложение с наименьшей
оценочной стоимостью, выполнить Контракт.
31.2 Согласно Статьям 6 и 16 ИУТ и как может быть
дополнительно указано в ИККП, при определении
квалификации
Участника
оцениваются
его
финансовые,
технические,
проектировочные,
управленческие, производственные возможности, а
Раздел I. Инструкции участникам торгов
51
также возможности по настройке, интеграции и
поддержке, путем изучения документальных
подтверждений квалификаций Участника и другой
информации,
которую
Покупатель
сочтет
необходимой и уместной. Такое определение может
включать посещение или собеседования с
клиентами Участника, упомянутыми в его
предложении, осмотры объектов и прочие действия.
Если разрешено в ИККП, в ходе последующего
квалификационного отбора могут быть проведены
тесты производительности и функциональности
предлагаемой Информационной системы на предмет
ее соответствия Техническим требованиям.
31.3 Положительный результат такого определения
квалификаций является необходимым условием
присуждения
Контракта
Участнику
торгов,
представившему предложение с наименьшей
оценочной стоимостью. Отрицательный результат
ведет к отклонению конкурсного предложения
Участника, причем в таком случае Покупатель
переходит
к
следующему
конкурсному
предложению с наименьшей оценочной стоимостью
для аналогичного определения возможностей
Участника удовлетворительно исполнить Контракт.
32. Критерии
присуждения
Контракта
32.1 В соответствии со Статьей 34 ИУТ, Покупатель
присуждает Контракт Участнику конкурса, чье
предложение признано в достаточной степени
отвечающим условиям Документации для торгов и
имеющим наименьшую оценочную стоимость, при
условии признания Участника квалифицированным
для удовлетворительного выполнения Контракта
согласно Статье 31 ИУТ.
33. Право Покупателя
изменить объемы
поставок в момент
присуждения
Контракта
33.1 Покупатель отставляет за собой право в момент
присуждения Контракта увеличить или уменьшить
на величину в процентах, указанную в ИККП,
следующие показатели поставок:
(a)
количество существенно схожих Подсистем;
или
(b)
количество отдельных видов Программного и
аппаратного обеспечения, сопутствующего
оборудования, Материалов, продуктов и
других Товаров, являющихся компонентами
Раздел I. Инструкции участникам торгов
52
Информационной системы; или
(c)
количество услуг по Установке, подлежащих
выполнению,
по сравнению с изначально указанными в
Технических требованиях (со всеми изменениями,
внесенными путем оформления Дополнений
согласно Статье 11 ИУТ), без изменения цены за
единицу продукции или других условий.
34. Право Покупателя
принять любое
конкурсное
предложение и
отклонить любое или
все конкурсные
предложения
34.1 Покупатель оставляет за собой право принимать или
отклонять любое конкурсное предложение, а также
прекратить процесс торгов и отклонить все
конкурсные предложения в любое время до
присуждения Контракта, не неся при этом никакой
ответственности перед Участниками торгов.
35. Уведомление о
присуждении
Контракта
35.1 До истечения срока действия конкурсных
предложений Покупатель письменно уведомляет
победившего Участника торгов о том, что его
предложение принято.
35.2 До подготовки и подписания официального
Контракта уведомление о присуждении Контракта
является обязывающим Контрактом.
35.3 Покупатель незамедлительно публикует результаты
торгов в UNDBonline и в dgMarket с указанием
номеров предложений и лотов, а также следующих
сведений: (i) наименования всех Участников торгов,
подававших конкурсные предложения; (ii) цены
конкурсных предложений, оглашенные в ходе
вскрытия конвертов; (iii) наименование, оценочная
стоимость и, если условия торгов включали
выставление оценки за техническое качество, то
Техническая
оценка
каждого
оцененного
конкурсного предложения; (iv) наименования
Участников торгов, чьи конкурсные предложения
были отклонены и причины их отклонения; и (v)
наименование победителя торгов, предложенную им
цену, а также срок действия и общий объем
поставок по присужденному Контракту. После
публикации результатов присуждения Контракта
проигравшие Участники торгов могут письменно
обратиться к Покупателю за разъяснением причин,
по которым не было принято их предложение.
Раздел I. Инструкции участникам торгов
53
Покупатель
должен
незамедлительно
дать
письменный
ответ
любому
проигравшему
Участнику,
который,
после
опубликования
информации о присуждении Контракта, запросит
такое разъяснение.
35.4 После того, как победитель торгов представит
подписанную Форму контракта и Залоговое
обеспечение выполнения Контракта в соответствии
со Статьей 37 ИУТ, Покупатель незамедлительно
уведомит всех проигравших Участников и возвратит
им Залоговое обеспечение их конкурсных
предложений в соответствии со Статьями 17.5(c) и
(d) ИУТ.
36. Подписание
Контракта
36.1 Одновременно с уведомлением победителя торгов о
присуждении ему Контракта Покупатель направляет
победившему
Участнику
включенное
в
Документацию для торгов Контрактное соглашение,
в котором зафиксированы все договоренности
между сторонами.
36.2 По возможности без промедления и не позже 28
(двадцати восьми) дней с момента получения
Контрактного соглашения, победитель торгов
обязан подписать его, поставить дату и вернуть
Покупателю.
37. Залоговое
обеспечение
выполнения
Контракта
37.1 По возможности без промедления и не позже
двадцати восьми (28) дней с момента получения
уведомления о присуждении Контракта от
Покупателя, победивший Участник торгов должен
представить Залоговое обеспечение выполнения
Контракта в соответствии с ОУК, с использованием
Формы залогового обеспечения выполнения
Контракта, включенной в Документацию для торгов
или в иной форме, приемлемой для Покупателя.
37.2 Неисполнение победителем конкурсных торгов
требований Статьи 36 ИУТ или Статьи 37.1 ИУТ
будет служить достаточным основанием для
аннулирования присуждения Контракта и, если
применимо, исполнения Гарантийной декларации
или удержания Залогового обеспечения, причем в
этом случае Покупатель может присудить Контракт
квалифицированному Участнику, представившему
следующее по величине оценочной стоимости
Раздел I. Инструкции участникам торгов
54
предложение, или объявить новый конкурс.
38. Третейский судья
38.1 Если иное не указано в ИККП, Покупатель
предлагает кандидата, указанного в ИККП, для
назначения Третейским судьей по Контракту, чья
роль предполагает неформальное посредничество в
разрешении спорных вопросов в рамках Контракта
согласно Статье 6 ОУК. В таком случае резюме
указанного
лица
прилагается
к
ИККП.
Предлагаемая почасовая ставка Третейского судьи
указывается в ИККП. Подлежащие возмещению
затраты Третейского судьи также указаны в ИККП.
Если Участник торгов не согласен с кандидатурой
Третейского судьи, предложенной Покупателем, он
должен приложить соответствующее заявление о
несогласии к своему конкурсному предложению и
внести встречную кандидатуру, указав почасовую
ставку вознаграждения и приложив резюме
кандидата. Если победитель конкурсных торгов и
Третейский судья, предложенный в ИККП,
оказываются из одной страны, причем не из страны
Покупателя, Покупатель оставляет за собой право
отозвать предложенную в ИККП кандидатуру
Третейского судьи и предложить новую. Если к
моменту подписания Контракта Покупатель и
победивший Участник не договорились о
назначении Третейского судьи, Третейский судья
будет назначен соответствующим уполномоченным
органом, указанным в Статье СУК, относящейся к
Статье 6.1.4 ОУК, или, если такой уполномоченный
орган там не определен, то Контракт будет
исполняться без Третейского судьи.
РАЗДЕЛ II. ИНФОРМАЦИОННАЯ КАРТА КОНКУРСНОГО
ПРЕДЛОЖЕНИЯ (ИККП)
Информационная карта конкурсного предложения
В данном разделе представлена специфическая информация связанная с
закупаемыми системами и процедурами закупок. В случае несоответствия положений
документации торгов преобладающей силой имеет положения изложенные в данном
разделе.
A. ОБЩИЕ ПОЛОЖЕНИЯ
ИУТ 1.1
Наименование Покупателя: Министерство здравоохранения
и социального развития Республики Казахстан.
Описание Системы, являющейся предметом торгов:
Поставка медицинских информационных систем для
организаций здравоохранения РК состоящий из следующих
лотов:
Лот № 1 «Поставка и внедрение комплексной
медицинской информационной системы для УстьКаменогорской городской больницы №1»;
Лот № 2 «Поставка и внедрение комплексной
медицинской информационной системы для ГКП на ПХВ
«Городская клиническая больница №4» г.Алматы»;
Лот № 3 «Поставка и внедрение комплексной
медицинской информационной системы для Центра
матери и ребенка г. Усть-Каменогорск»;
Лот № 4 «Поставка и внедрение комплексной
медицинской информационной системы для Городской
поликлиники № 11 г.Алматы»;
Лот № 5 «Поставка и внедрение комплексной
медицинской
информационной
системы
для
Регионального диагностического центра г.Алматы»;
Лот № 6 «Поставка и внедрение комплексной
медицинской информационной системы для Поликлиники
№1 города Костанай»;
Лот № 7 «Поставка и внедрение комплексной
медицинской информационной системы для Центральной
районной больницы Жуалинского района Жамбыльской
области»;
Лот № 8 «Поставка и внедрение комплексной
медицинской информационной системы для Городской
поликлиники №7 г.Астаны»;
Лот № 9 «Поставка и внедрение комплексной
медицинской информационной системы для Городской
больницы №1 г.Астаны»;
ИУТ 1.2
Лот № 10 «Медицинская информационная система для
учета доноров и реципиентов».
Название ПУТ: Поставка медицинских информационных
систем для организаций здравоохранения РК
Номер ПУТ: № KHSTTIRP-D/SW-03-повторный.
Название соответствующего контракта: KHSTTIRP-D/SW-03повторный «Поставка медицинских информационных систем
для организаций здравоохранения РК».
ИУТ 1.4
ИУТ 2.1
ИУТ 6.1 (a)
Альтернативная процедура электронных торгов не возможна
Наименование Заемщика: Республика Казахстан
Номер займа или кредита: Займ № 4883-KZ
Сумма займа или кредита: US$ 117 700 000
Название проекта: Проект по передаче технологий и
проведению институциональной реформы в секторе
здравоохранения
Квалификационные требования к Участникам торгов:
(a)
Участник
должен
документальное
доказательство
следующим финансовым требованиям:
-
предоставить
соответствия
Средний годовой оборот в долларах США или
эквивалент в течении последних 3 лет (2012, 2013 и
2014 годы):
- не менее US$1,500,000.00 (одного миллиона пятисот
тысяч долларов США) для Лота № 1 «Поставка и
внедрение комплексной медицинской информационной
системы для Усть-Каменогорской городской больницы
№1»;
- не менее US$1,000,000.00 (одного миллиона долларов
США) для Лота № 2 «Поставка и внедрение комплексной
медицинской информационной системы для ГКП на ПХВ
«Городская клиническая больница №4» г.Алматы»;
- не менее US$2,000,000.00 (двух миллионов долларов
США) для Лота № 3 «Поставка и внедрение комплексной
медицинской информационной системы для Центра
матери и ребенка г. Усть-Каменогорск»;
- не менее US$1,000,000.00 (одного миллиона долларов
США) для Лота № 4 «Поставка и внедрение комплексной
медицинской информационной системы для Городской
поликлиники № 11 г.Алматы»;
- не менее US$1,000,000.00 (одного миллиона долларов
США) для Лота № 5 «Поставка и внедрение комплексной
медицинской
информационной
системы
для
Регионального диагностического центра г.Алматы»;
- не менее US$1,000,000.00 (одного миллиона долларов
США) для Лота № 6 «Поставка и внедрение комплексной
медицинской информационной системы для Поликлиники
№1 города Костанай»;
- не менее US$1,000,000.00 (одного миллиона долларов
США) для Лота № 7 «Поставка и внедрение комплексной
медицинской информационной системы для Центральной
районной больницы Жуалинского района Жамбыльской
области»;
- не менее US$1,000,000.00 (одного миллиона долларов
США) для Лота № 8 «Поставка и внедрение комплексной
медицинской информационной системы для Городской
поликлиники №7 г.Астаны»;
- не менее US$1,000,000.00 (одного миллиона долларов
США) для Лота № 9 «Поставка и внедрение комплексной
медицинской информационной системы для Городской
больницы №1 г.Астаны»;
- не менее US$1,500,000.00 (одного миллиона пятисот
тысяч долларов США) для Лота № 10 ««Медицинская
информационная система для учета доноров и
реципиентов».
Если Участник является СП, то может быть
применена сумма среднего годового оборота всех
участников. Если Участник является СП, то
ответственный партнер должен иметь средний
годовой оборот в эквиваленте не менее половины
требуемой суммы за последние 3 года, а каждый
партнера, в размере 10 % от общей потребности.
Участник
должен
представить
аудиторские
финансовые ведомости и баланс счетов (или другие
документы, предусмотренные законодательством
страны участника торгов) за последние завершенные
3 финансовых года, показывающие устойчивость
финансовой позиции Участника и необходимые
ресурсы, которыми он владеет в целях соответствия
требованиям предложенного контракта.
Если участник претендует на присуждение
контракта по более чем одному лоту, тогда он
должен продемонстрировать наличие необходимого
среднего годового оборота для соответствия
совокупности квалификационных требований по
индивидуальным лотам
(b)
Опыт и технические способности
Участник должен предоставить документальное доказательство
(включая информацию о завершенных контрактах и контактной
информации заказчиков которые могут предложить отзывы и
которых Покупатель при необходимости может посетить,
чтобы ознакомится с системами, введенными в эксплуатацию
Участником) доказывающее его соответствие следующим
требованиям к опыту:
i.
Участник торгов должен функционировать как
минимум в течение последних 5 лет и основной
частью его бизнеса должна быть поставка, разработка
и внедрение медицинских информационных систем
для организаций здравоохранения.
ii.
Производители ПО должны иметь как минимум
один сертификат из следующего перечня: Capability
Maturity Model Integration (CMMI) Maturity Level 3,
ISO 9000 или СТ РК ИСО 9001:2009, или
аналогичных для процесса управления качеством.
(Участник должен предоставить копию сертификата
соответствия, выданного уполномоченным органом).
iii.
Участник должен иметь опыт в обучении конечных
пользователей и специалистов ИТ.
iv.
Участник торгов должен иметь доказанный опыт в
создании схожих проектов: не менее 5 медицинских
организаций используют в настоящее время системы
разработанные или внедренные Участником торгов
(желательно чтобы масштаб данных медицинских
организаций
соответствовал
Организациям
–
бенефициариев данного тендера или был больше).
"Доказанный" означает предоставление контактов,
адресов, писем и других документов способных
подтвердить использование (и результаты) Системы,
требуемых согласно этого контракта.
Участник торгов должен иметь свою собственную
команду с опытом внедрения похожих проектов.
Участник торгов должен предоставить таблицу со
списком сотрудников с указанием их резюме для
доказательства опыта и знаний. Детальные
требования к команде указаны в Разделе VI
«Технические требования» пункте R10.4 для лотов №
1-9 и R11.4 для лота № 10. Участник торгов должен
предоставить два набора резюме для того чтобы ему
присудили два лота и три набора резюме чтобы ему
присудили три лота
Участник торгов должен представить все документы
происхождения для всех компонентов и продуктов,
включая разрешение производителя использовать
продукты для данного контракта или предоставить
подтверждение о наличии прав на продукты (патент,
или другие документы), включая право на
Интеллектуальную
Собственность
и
другие
относящиеся права.
Участник
торгов
(или
члены
совместного
предприятия) должны иметь доказанный опыт
работы с одним или несколькими стандартами,
используемыми в настоящем документе: HL7 v2, v3,
v.
vi.
vii.
FHIR, CDA (R2). IHE.
ИУТ 6.1 (b)
ИУТ 6.1 (c)
Для поставки перечисленных далее типов и категорий
Информационных технологий, за исключением тех, которые
изготовлены самим Участником торгов, необходимы
Полномочия от Изготовителя: для операционных систем,
лицензионного программного обеспечения.
Если Участник предлагает использовать Субподрядчиков для
обеспечения неких ключевых сервисных функций, то, в случае
заключения контракта требуется предоставление письменных
договоров с предлагаемыми фирмами на осуществление
следующих
типов/категорий
функций:
кастомизация
программного обеспечения, обучение, и, в особенности
гарантийное и послегарантийное обслуживание оборудования.
B. ДОКУМЕНТАЦИЯ ДЛЯ ТОРГОВ
ИУТ 10.1
Адрес Покупателя:
Группа поддержки реализации проекта,
010000, Казахстан, г. Астана, ул. Иманова 19, офис 504,
Телефон: + 7172 787 235
Факс: + 7172 787 247
e-mail: kazhealth.procurement@gmail.com
Контактное лицо:
Болат Токежанов –Национальный координатор проекта
Полный комплект документации для торгов на английском языке
в форматах PDF и Word можно также скачать на сайте проекта
healthproject.kz после прохождения процедуры регистрации.
При появлении разночтений между документами в форматах PDF
и Word, файл PDF будет иметь превалирующее значение.
К тому же заинтересованные участники торгов могут получить
полный комплект документации для торгов на русском языке в
формате Word. При появлении разночтений между английской и
русской версией документа, английская версия будет иметь
превалирующее значение.
Разъяснения будут
www.healthproject.kz
ИУТ 10.2
ИУТ 11.2
также
публиковаться
на
веб-сайте
Число, время и место проведения предтендерного совещания:
нет
Изменения к Конкурсной документации будут также
публиковаться на веб-сайте www.healthproject.kz
C. ПОДГОТОВКА КОНКУРСНЫХ ПРЕДЛОЖЕНИЙ
ИУТ 12.1
Все письма и документы, касающиеся конкурного предложения,
должны быть написаны на: английском языке
ИУТ 14.1
ИУТ 14.4
ИУТ 14.4 (a)
ИУТ 14.4 (c)
ИУТ 14.7
ИУТ 15.1 (b)
ИУТ 16.2 (c)
Для облегчения оценки предложений участников торгов
покупатель просит также представить перевод их заявки на
русский язык. Тем не менее, отсутствие перевода не является
причиной для отклонения заявки или оценки этого
Конкурсного предложения. В случае расхождения между
английской версией и переводом, предложение на английском
языке будет превалировать.
Текущие расходы не требуются.
Используется следующее издание ИНКОТЕРМС:
“ИНКОТЕРМС 2010”.
Информацию о самой последней версии ИНКОТЕРМС можно
получить на сайте МТТ по адресу:
http://www.iccwbo.org/index_incoterms.asp
Для инностранных товаров цена указывается на условиях
поставки:
СИП-Астана для лотов №8, №9 и №10.
СИП-Усть-Каменогорск для лотов №1 и №3.
СИП-Алматы для лотов №2, №4 и №5.
СИП-Костанай для лота №6.
СИП-Тараз для лота №7.
(i)
договор о транспортировке должен включать стоимость
разгрузки товаров в пункте назначения, а также оплату
Поставщиком таможенного оформления, пошлин, налогов и
прочих сборов, взимаемых с иностранных Товаров за
транзитную транспортировку через любую страну, не
являющуюся страной Покупателя.
(ii) Названными пунктами назначения являются “Проектные
площадки” указанные в таблице «Перечень (перечни)
площадок Системы ».
не применимо
Заявленные Участником торгов цены должны оставаться
неизменными.
Цены на входящие в состав Системы местные Товары и Услуги,
т.е. Товары и Услуги, поставляемые с территории Страны
Покупателя, а также расходы в местной валюте на оказание
местной технической поддержки, обучение персонала,
техническое обслуживание, транспортировку, страхование и
предоставление других местных услуг, связанных с доставкой,
установкой и эксплуатацией Системы, выражаются в:
казахстанских тенге.
В дополнение к тому, что перечислено в Статье ИУТ 16.2 (c), в
Предварительном плане проекта должны рассматриваться
следующие вопросы:
(а) План организации менеджмента проекта, в котором будет
описаны роли и ответственность персонала Поставщика, с
указанием имен и количество времени работы (человекомесяцы), а также описаны какие действия менеджмента и
персонала медицинской организации необходимы для
успешного выполнения проекта
(б) План внедрения систем (ы) в медицинской(их)
организации(ях), который бы доказал, что все требования
ИУТ 16.3
ИУТ 17.1
покупателя для поставляемых систем выполнены, и это
подтверждено организацией бенефициарием, и что системы
сертифицированы в соответствии с требованиями покупателя
(в) Методология и План разработки / конфигурации,
тестирования,
установки, опытной эксплуатации и
сертификации поставляемых систем
(г) Методология и план обучения пользователей с указанием
методов и программы обучения, количества часов, места
предоставления тренингов и передачи технологий как для
пользователей, так и для менеджеров предприятия.
(д) План миграции данных (если существуют такие данные)
(е) План реакции при гарантийном обслуживании и
предоставлении профессиональных услуг при пилотировании:
какова время ответа на устранения ошибок и запросов, указать
где будет находиться персонал поставщика, сколько человек
будут задействованы и по какому графику.
(ж) Методология и план технической поддержки всего
поставляемого ПО и компонент, как во время внедрения, так и
при опытной эксплуатации
В интересах эффективного осуществления интеграции,
оказания экономически выгодной технической поддержки и
сокращения расходов на переобучение персонала и
комплектование кадров, Участники торгов должны предлагать
конкретные бренды и модели для ограниченного круга
перечисленных далее конкретных позиций: Не применимо.
Конкурсное предложение «должно» включать залоговое
обеспечение в форме банковской гарантии. Сумма залогового
обеспечения конкурсного предложения должна составлять:
- 20 000 долларов США для Лота № 1 «Поставка и
внедрение комплексной медицинской информационной
системы для Усть-Каменогорской городской больницы
№1»;
- 10 000 долларов США для Лота № 2 «Поставка и
внедрение комплексной медицинской информационной
системы для ГКП на ПХВ «Городская клиническая
больница №4» г.Алматы»;
- 30 000 долларов США для Лота № 3 «Поставка и
внедрение комплексной медицинской информационной
системы для Центра матери и ребенка г. УстьКаменогорск»;
- 10 000 долларов США для Лота № 4 «Поставка и
внедрение комплексной медицинской информационной
системы для Городской поликлиники № 11 г.Алматы»;
- 10 000 долларов США для Лота № 5 «Поставка и
внедрение комплексной медицинской информационной
системы для Регионального диагностического центра
г.Алматы»;
- 10 000 долларов США для Лота № 6 «Поставка и
внедрение комплексной медицинской информационной
системы для Поликлиники №1 города Костанай»;
- 15000 долларов США для Лота № 7 «Поставка и
внедрение комплексной медицинской информационной
системы для Центральной
районной больницы
Жуалинского района Жамбыльской области»;
- 10 000 долларов США для Лота № 8 «Поставка и
внедрение комплексной медицинской информационной
системы для Городской поликлиники №7 г.Астаны»;
- 10 000 долларов США для Лота № 9 «Поставка и
внедрение комплексной медицинской информационной
системы для Городской больницы №1 г.Астаны»;
ИУТ 18.1
- 20 000 долларов США для Лота № 10 ««Медицинская
информационная система для учета доноров и
реципиентов».
Срок действия конкурсных предложений составляет 120 дней
после наступления срока подачи конкурсных предложений,
указанного далее в ссылке на Статью ИУТ 21. Соответственно,
каждое конкурсное предложение действительно вплоть до 10
февраля 2016 года.
Срок действия банковской гарантии истекает 9 марта 2016 года.
ИУТ 19.1
Необходимо представить: 1 оригинал и 5 копий конкурсного
предложения.
D. ПОДАЧА КОНКУРСНЫХ ПРЕДЛОЖЕНИЙ
ИУТ 20.2 (a)
Адрес для подачи конкурсных предложений:
010000, Казахстан, г. Астана, ул. Иманова 19, офис 504,
Болату Токежанову –Национальному координатору проекта
ИУТ 21.1
Конкурсные предложения должны быть представлены не
позднее: 15 ч. 30 мин, 15 октября 2015 года.
E. ВСКРЫТИЕ И ОЦЕНКА КОНКУРСНЫХ ПРЕДЛОЖЕНИЙ
ИУТ 24.1
Час, день и место вскрытия конкурсных предложений: 15 ч. 30
мин, 15 октября 2015 года.
010000, Казахстан, г. Астана, ул. Иманова 19, офис 504,
ИУТ 27.1
Для целей перевода в единую валюту выбрана: KZT (тенге)
Источником обменного курса является: Национальный Банк
Республики Казахстан
Датой обменного курса является: Дата вскрытия конкурсных
предложений
ИУТ 28.1
Ценовые предложения по подсистемам, лотам, частям всей
информационной
системы
будут
приняты.
Ценовые
предложения будут оценены по каждому лоту отдельно.
Участникам не разрешается предоставлять свои технические
решения другим участникам, участвующим в том же конкурсе
Если участник желает предложить безусловную скидку по
любой комбинации двух или трех лотов такой участник может
сделать такое предлагая только одну такую скидку которая
будет выражена в процентах к общей стоимости комбинации
двух или трех лотов. Такая предлагаемая скидка будет учтена
для целей определения наименьшей стоимости комбинаций
лота (контракта).
Участник торгов может предложить индивидуальные
безусловные скидки на заявленную цену по одному или
нескольким индивидуальным лотам при этом соответствующая
скидка, предлагаемая по каждому лоту, будет рассматриваться
для целей оценки. Если такой участник также предложил
единую безусловную скидку для комбинации двух или трех
лотов как указано выше, скидка будет применяться к чистой
цене конкурсного предложения, полученной после вычета
значения предложенных индивидуальных безусловных скидок
ИУТ 28.4
В процессе оценки конкурсных предложений технические
факторы не будут учитываться в дополнение к ценовым
факторам. Вес цены составляет 100%.
ИУТ 28.6 (c) (i)
Покупатель не будет принимать отклонения от графика
установки Системы и ее ввода в эксплуатацию, который
приведен в Графике реализации.
Покупатель не будет
принимать отклонения от графика
платежей, приведенного в СУК.
ИУТ 28.6 (c) (ii)
F. ПОСЛЕДУЮЩИЙ КВАЛИФИКАЦИОННЫЙ ОТБОР И
ПРИСУЖДЕНИЕ КОНТРАКТА
ИУТ 31.2
ИУТ 32.1
ИУТ 33.1
Не применимо.
Контракт(ы) будут присуждены участнику или участникам
предлагающим наименьшую стоимость для Покупателя по
комбинированным лотам при условии, что отобранный
участник
торгов
соответствует
необходимым
квалификационным критериям по лоту или комбинации лотов
при необходимости. Покупатель присудит не более трех лотов
одному участнику торгов, даже если участник торгов
предложил наименьшую цену и был высоко оценен по
квалификации.
В случае, если конкурсное предложение одного или нескольких
участника торгов получит наименьшую оцененную стоимость
по более чем трем лотам, критерием выбора лотов для
покупателя будет являться наилучшая, с точки зрения,
покупателя комбинация общей стоимости всех присуждаемых
лотов
Количественные величины могут быть увеличены или
ИУТ 38.1
уменьшены на: 15% .
В качестве Третейского судьи предлагается
WEINHARA Michael, Магистр наук по медицинской
информатике.
Резюме,
прилагается
к
настоящей
Информационной карте конкурсного предложения.
Предлагаемый размер оплаты составляет 350 (триста
пятьдесят) долларов США в час.
К числу расходов, которые будут компенсироваться
Третейскому судье, относятся:
расходы на телефонные
переговоры, передачу факсимильных сообщений и прочие
услуги связи, понесенные в связи с рассмотрением данного
спора, а также все расходы (если таковые имеются),
понесенные в связи с посещением места (мест) реализации
проекта.
Приложение к Разделу II. Информационная Карта Конкурсного
Предложения (ИККП)
Статья ИУТ 3: положения ИУТ 3.1 до 3.3 заменены следующим включая
соответствующие сноски:
3.
Мошенни
чество и
коррупци
я
В соответствии со своей политикой Банк требует,
чтобы в рамках контрактов, финансируемых Банком, заемщики
(включая бенефициаров займов Банка), а также участники торгов,
поставщики, подрядчики и их субподрядчики соблюдали самые
строгие нормы этики в процессе закупок и выполнения таких
контрактов1. В обеспечение такой политики Банк:
3.1
(a)
дает изложенные далее определения следующим
терминам для целей настоящей статьи:
«коррупция» означает прямое или косвенное предложение,
передачу, получение или вымогание любой ценности с целью
оказать ненадлежащее влияние на действия другой стороны;2
(i)
«мошенничество» означает любое действие или упущение,
включая дезинформацию, которое умышленно или по
неосторожности вводит в заблуждение или пытается ввести в
заблуждение сторону3 с целью получения финансовой или другой
выгоды или уклонения от выполнения обязательства;
(ii)
«сговор» означает договоренность между двумя или более
сторонами имеющую ненадлежащую цель, включая оказание
влияние на действия другой стороны4;
(iv)
«принуждение» означает нанесение повреждения или
ущерба или угроза нанесения повреждения или ущерба напрямую
или косвенно другой стороне или собственности другой стороны с
целью оказания ненадлежащего влияния на действия другой
стороны;5
(iii)
1
В данном контексте, любое действие, предпринятое участником торгов, поставщиком, подрядчиком
или субподрядчиком с целью оказать влияние на процесс закупки или исполнение контракта для
получения неправомерного преимущества, считается ненадлежащим.
2
Под «другой стороной» понимается должностное лицо, имеющие отношение к процессу закупки или к
исполнению контракта. В данном контексте «должностные лица» включают сотрудников
Всемирного Банка и других организаций, принимающих решения по закупкам, или проверяющих их.
3
Под «стороной» понимается должностное лицо, понятия «выгода» и «обязательство» применимы к
закупочному процессу или исполнению контракта, а «действие или упущение» направлены на
оказание влияния на закупочный процесс или исполнение контракта.
4
Под «сторонами» понимаются участники закупочного процесса (включая должностные лица),
пытающиеся установить цены предложений на искусственном неконкурентном уровне.
5
Под «сторонами» понимаются участники закупочного процесса или исполнения контракта
(v)
«обструкционистская практика» это
(аа) намеренное уничтожение, фальсификация,
изменение или сокрытие подтверждающей
информации при проведении расследования
или ложное заявление для того, чтобы
фактически затруднить расследование Банка
по обвинению в коррупции, мошенничестве,
сговоре или насилии и принуждении; и/или
угроза, притеснение или запугивание любой
из сторон, с целью помешать этой стороне
обнародовать известные ей обстоятельства,
относящиеся
к
расследованию,
или
проводить расследование; или
(bb) действия,
направленные на то, чтобы
фактически помешать Банку воспользоваться
своими правами на проведение инспекции и
аудита, предусмотренных параграфом 3.2,
приведенном далее.
a
(b)
отклонит предложение о присуждении Контракта, если
придет к выводу о том, что рекомендуемый для
присуждения Контракта Участник торгов, сам или через
своего представителя, был замешан в коррупции,
мошенничестве,
сговоре,
принуждении
или
обструкционизме в процессе конкуренции за получение
данного Контракт;
(c)
аннулирует ту часть займа, которая предназначена для
финансирования контракта, если в какой-либо момент
времени будет установлено, что представители
Заемщика или бенефициара займа были замешаны в
коррупции, мошенничестве, сговоре или принуждении
в процессе проведения отбора или выполнения того
контракта, а Заемщик при этом не принял
своевременные и надлежащие меры по исправлению
ситуации, удовлетворительные для Банка
(d)
в любой момент наложит на фирму или индивидуала
санкции согласно превалирующим процедурам Банкаa,
включая публичное обяъвление данной фирмы или
консультанта неправомочными, на неограниченное время
либо на указанный срок:(i) на награждение контрактом
финасируемым Банком; и (ii) быть номинированым в
фирма или индивидуальный консультант может быть объявлен неправомочным на
награждение контрактом финансируемого Банком контракта после завершения процедур
Банка по наложению санкций включая, inter alia: (i) временное приостановление ввиду
текущих процедур санкции; (ii) встречного лишения прав по согласованию с другими
межуднародными финансовыми институтами включая международные банки развития; и
(iii) корпоративные административные санкции группы ВБ по мошенничествуи коррупции.
качестве b подрядчика, консультанта, производителя или
поставщика, поставщика услуг награжденного контрактом
Банка.
в целях следования данной политики участник торгов разрешает
Банку проверку их счетов, учетной и другой документации,
связанной с подачей предложений и выполнением контрактов, а
также на проведение аудита этих документов аудиторской
фирмой, назначенной Банком.
3.2
3.3
Кроме того, Участники торгов должны быть осведомлены об
условиях, оговоренных в Статье 9.8 и Статье 41.2 Общих
условий контракта.
Статья ИУТ 4 (Правомочные участники торгов): положения
ИУТ 4.3 заменено следующим включая соответствующие сноски:
Фирма, объявленная Банком неправомочной в
соответствии со Статьей ИУТ 3.1 (d) или Руководством
Банка «О предотвращении и борьбе с коррупцией и
мошенничеством в проектах, финансируемых займами
МБРР и кредитами МАР» не может быть правомочна для
присуждения контракта, или получать выгоду от контрактов
4.3
финансируемых Банком, финансово или иным путем, в течении
периода времени установленного Банком. Список фирм
отстраненных от участия в проектах Всемирного Банка
размещен
на
сайте
указанном
в
ИККП
(http://web.worldbank.org/external/default/main?theSitePK=84
266&contentMDK=64069844&menuPK=116730&pagePK=64
148989&piPK=64148984).
b
назначенный подрядчик, консультант, производитель или поставщик, поставщик услуг
(различные названия используются в документации для торгов) это лицо которое:(i) было
включено участником торгов в предварительное квалификационное заявление или
конкурсное предложение потому что оно вносит специфический или критический опыт и
ноу-хау которые оценены в пре-квалификационном заявлении или конкурсном предложении
участника торгов; или (ii) назначены Заемщиком.
РЕЗЮМЕ
Фамилия: WEINHARA
Имя:
Michael
Дата рождения: 23/07/1962
Национальность: немец
Социальный статус: женат, одна дочь
Образование:
Институт [дата начала – дата завершения] Полученные степени и дипломы
УниверсистетВалден, балтимор (Walden
Магистр наук по медицинской информатике
University, Baltimore)
02.2012 – 03.2014
Рейнланд-группакадемия (TÜVАудитор медицинских институтов
Rheinland-Group Academy), Cologne,
04.2005
Профессиональный университет
Оценщик EFQM
Steinbeis, Европейская федерация по
управлению качеством, Берлин, 10.2004
«МудиИнтернашэнэл»техническаяинспек Аудитор системы управления качеством /
цияуслуг (Moody International IRCA Cert), ведущий аудитов, ISO 9001
Пфорцеим,
04.2003
АкадемияУправления и экономики,
B.A. управление больницей
Кемптен (Management and Economy
Academy, Kempten),
08.1996 – 07.1998
Центрусовершенствования, Мюнхен
Управление персоналом больницы
(Centre of Advanced Vocational Education,
Munich),
10.1990 – 09.1992
Школа сестринского дела (School of
Зарегистрированная медсестра
Nursing, Kaufbeuren),
09.1979 – 08.1982
7.
Навыки знания иностранных языков: укажите компетенцию по шкале от 1 до 5 (1
– отлично; 5 – базовый уровень)
Язык
Чтение
Речь
Письмо
Немецкий
Родной
Родной
Родной
Английский
1
1
1
Албанский
5
5
5
Индонезийский
5
5
5
8. Членство в профессиональных организациях: Европейская организация по качеству
ЕОК, Европейского института медицинских записей (EuroRec), Немецкой Ассоциации
медицинской информатики (GMDS), HL7,
9. Другие навыки: архитектура и функциональность ЭЗЗ, Руководитель группы
экспертов по реализации ИС здравоохранения, опыт планирования работы больницы,
расчет бюджета больниц, чтение лекций, разработки учебной программа, анализ
1.
2.
3.
4.
5.
6.
рабочего потока больницы, опыт FMEA, знание профсоюзной работы, опыта
реализации системы менеджмента качества, MSOffice (экспертные знания), FTP,
реляционные базы данных, веб-дизайн, арбитр при закупе модуля ИС для
TongaHealthHospital, арбитр на поставку и установку оборудования и программного
обеспечения для проекта Молдова М-Cloud.
10.
Настоящая позиция: руководитель команды экспертов для проекта по строительству
больниц и повышения потенциала
11.
Срок работы в фирме: 5+ лет
12.
Ключевые квалификации:
 Старший консультант с 20 летним опытом работы в области управления
больницами и управления качеством, разработке ИС в которых 12 лет
опыта в качестве технического консультанта по развитию проектов по
всему миру;
 Фок ус на консультационные услуги, по: ISO 9001 и EFQM согласно
системам управления качеством, техническая поддержка больниц, рабочее
место, проект реестра обязанностей и описание работы, управление
информацией больниц, планирование человеческих ресурсов, кальк уляция
бюджета;
 Хорошо осведомлен о стандартах ВОЗ и других стандартах по кач еству;
 Оценка пробелов и потребностей, а так же оценка качества и управление
изменениями и его процессы;
 Опыт планирования ф ункционального дизайна больницы и об учение
пользователей по управлению больницами;
 Опыт анализа и обновления учебного плана по спе циальности
«Сестринское дело», структ урное планирование и док ументация по
сестринской службе.
 Большой опыт в разработке и реализации ИС по управлению
здравоохранением на всех уровнях, включая прикладн ую Телемедицин у.
 Опыт анализа и обновления всех процесс ов управления больницами;
 Опыт работы в международной системе медицинского кодирования для
всех 3 уровней здравоохранения;
 Анализ структ ур управления, использование индикаторов эффективности,
ул учшение существующих структ ур сбора данных, сокращение излишни х
структ ур сбора данных;
 Опыт работы в повышении потенциала включая разработку и реализацию
профессионального обучения по всестороннему управлению качеством,
сестринской службе, управлению информацией, планированию ресурсов,
организаций здравоохранения;
 Большой опыт работы в развитии СОП, описания работ и планировании
рабочих потоков.
 Опыт в укреплении дисциплины на рабочем месте.
 Эффективная работа по созданию сети контактов и переговоров, навыки.
Специфический опыт работы в регионе:
Страна
Дата
Страна
Уганда
1986 – 1987
Косово
Албания
2002
Вьетнам
Индонезия
2005 – 2007
Сирия
Замбия
2007 – 2008
Сербия
Таджикистан
2010
Грузия
Афганистан
2008 – по настоящее время
Пакистан
13.
Дата
2000 – 2006
2003 – 2004 + 2010 – 2011
2006
2007 - 2008
2009
2013 - 2014
14.
Дата
08.20
08 –
по
насто
ящее
время
Профессиональный опыт:
место
Компания
Афгани EPOS,
стан
KfW German
«Mazar- Development Bank
e-Sharif
Thomas Herzberg KfW
Kunduz» North
AfghanistanThomas.He
rzberg@kfw.de
08.20
13 03.20
14
Пакиста
н
Пешава
р
FATA
AGEG Consultants /
KfW German
Development Bank
Clemens Lässing
c.laessing@ageg.de
11.20
10 –
04.20
11
Вьетнам
GFA Consulting Group
EC Delegation Director
Medical
joachim.gromotka@gfa
-group.de
02.20
10 –
11.20
10
Таджик
истан
Душанб
е
Худжан
д
Грузия
04.20
09 –
Ханой
Euro Health Group
/World Bank
Marina Budeyeva
Team Leader
m_budeyeva@yahoo.c
om
Sofreko, Conseil Santè
, World Bank Maia
Позиция
Руководи
тель
команды
экспертов
в двух
проектах
в течении
13
месяцев
Краткоср
очный
консульт
ант /
Руководи
тель
команды
эксперто
в
Краткоср
очный
консульт
ант /
Руководи
тель
команды
эксперто
в
Краткоср
очный
консульт
ант
Описание
Менеджмент и координация реконструкции больницы в провинции Mazar-eSharif стоимостью €
13 миллионовна площади16.000м², строительство новой крыши на 360 коек. Общая
координация проекта между всеми заинтересованными сторонами, создание потенциала для
больничного управления во всех аспектах TQM, бюджету и планированию HR, устойчивого
качества обслуживания. Завершено и открыто в декабре 2011 года. Кроме того, назначен в
ноябре 2010 руководителем группы по проекта реконструкции больницы в € 32 в Северном
Афганистане. Контроль качества, развитие структур обслуживания, внедрение прикладной
телемедицины и теле-гистопатологии.
Краткоср
очный
Разработка политических рекомендации, чтобы поддержать развитие сестринского
образования; оценка потенциала образовательных учреждений, предоставляющих сестринское
Управление реализации поддержки для национальной программы по борьбе с туберкулезом,
поставку мобильное пунктов здравоохранения, здоровья матери и ребенка, поставка скорой
помощи, консультационные услуги по логистике и координации проекта с Федеральной
Администрацией территории племен (FATA) в Северном Вазиристане, Южном Вазиристане и
Хайбер-Пахтунхва. € 5,3 млн..
Оценка состояния ИС здравоохранения, инвентаризация рабочих процессов в области
управления данными на предприятии района, провинциальных больниц и на уровне
министров: Разработка стратегического плана действий по ИС здравоохранения с
техническими решениями на различных уровнях сотрудничества с МЗ, применение структур
ВОЗ; проект ТЗ на тендер по программе реализации ИС здравоохранения и необходимого
оборудования.
Техническая помощь в разработке и внедрении информационной системы управления
здравоохранением в центрах первичной медицинской помощи, больничных учреждений и
областных департаментов здравоохранения. Фокус на управленческих показателях для
начальных и средних руководителей предприятий и региональных руководителей отделов
здравоохранения. Обзор структурных требований к улучшению качества данных.
11.20
09
Тбилиси
01.20
10 –
12.20
10
Афгани
стан
12.20
07
02.08
Германи
я
05.20
07
07.20
08
Сербия
05.20
07 –
07.20
08
Замбия
05.20
05 10.20
Индонез
ия
Кабул
Бранден
бург
Белград
Лусака
Gogashvili
University of Georgia
Tbilisi
gogashvilim@yahoo.co
m
EPOS Health
Management /
AFD French
Development Bank
Roger Fergusson Team
Leader ,
Roger.Ferguson@epos.
de
AWO Königswusterhausen
Grit Marko head of
TQM
Telephone:
+4933755144 90
Euro Health Group
EAR Dr Matthias
Reinicke Task Manager
Health, European
Agency for
Reconstruction
mwreinicke@googlema
il.com
CESO CI
EUROPEAID/119860/
C/SV/multi Dr.
Christopher Simoonga
Ministry of Health,
simoongachris@yahoo.
com
Saniplan EU
IDN/AIDCO/2002/040
9
консульт
ант
Краткоср
очный
консульт
ант
консульт
ант
образование; выработки рекомендаций для компетенций, профессиональных стандартов в
области сестринского образования; Формулирование рекомендаций по стандартам для
учреждений по сестринскому образованию и необходимых институциональных изменений в
свете этих новых стандартов. Анализ пробелов в структурах управления качеством в области
сестринского образования.
Техническая помощь для диагностических центров и банка крови управления Министерства
здравоохранения Афганистана.
Координация между архитектором и соответствующими департаментами Министерства
градостроительства и Mминистерства общественного здравоохранения в получении
разрешение на строительство и функциональных проектных работ; сотрудничество с
организацией по реконструкции и развитию услуг Афганистана (ОРДС) в рамках подготовки
тендера на строительство и поставок.
Поддержка и коучинг руководства в создании и реализации ISO 9001:2000 и EFQM
совместимых структур в доме пенсионера на 400 мест в 4 местах в регионе Бранденбург.
Руководи
тель
команды
эксперто
в
Внедрение электронных медицинских записей (ЭМК) в Сербии: общая ответственность за
управление проектом; техническая помощь в закупке услуг, оборудования и работ,
заключенных отдельно от основного договора технической помощи; Разработка и обеспечение
качества тестирования системной архитектуры, программных модулей и базы данных;
развертывание и интеграция программных модулей и сторонних связей программных
компонентов; Производительность и мониторинг окружающей среды.
Руководи
тель
команды
эксперто
вSTE
Оценка потребности в практическом и теоретическом обучении для сотрудников программы
ИСЗ на национальном, провинциальном и окружном уровнях;
Обзор существующих программ подготовки ИСЗ на всех уровнях; Разработка программ
обучения до и в процессе эксплуатации программы обучения для всех уровней сектора
здравоохранения, поддержка и мониторинг деятельности HMIS пред-и в процессе
эксплуатации программ, на всех уровнях;
Эксперт
по ИС
здравоох
ИС здравоохранения для проекта “Поддержка Сообществу медицинских услуг в южной
Суматре, Джамби и Папуа, Индонезия”: серия 15 заданий в поддержку МЗ Индонезии и
районных директоратов здравоохранения в 8 районах Индонезии: анализ структур
07
Джакарт
а
Суматра
Папуа
2005
2006
Германи
я
Множес
тво мест
10.20
06
11.20
06
Сирия
02.20
02 03.20
06
Косово
02.20
06 10.20
06
Косово
Дамаск
Пристин
а
Призрен
Mr Philip Constable,
Team Leader
p.740@btinternet.com
5 Lakeside, Darlington,
Co Durham, DL3 5TH,
UK
TÜV Rheinland Group
/ LGA InterCertLead
Auditor
Barbara-Wagemann@tonline.de
+491601490549
Options/GTZ/EPOS
funded by EU
(HSMP)SYR/AIDCO/2
001/0215
Prof. Ulrich Laaser
University of Bielefeld
ulrich.laaser@unibielefeld.de
BernardBrunhesInterna
tional,
IRISConseilSanté,
HLSP
DrMatthiasReinickeTas
kManager Health,
European Agency for
Reconstruction
mwreinicke@googlema
il.com
SOFRECO / Grand
Duchy of Luxembourg
YUG/00503229 A
Mike Lamb Team
Leader Mobile +44 (0)
7777685237
mikelamb230@hotmail
ранения
(Краткос
рочный
200
дней)
Аудитор
Краткоср
очный
консульт
ант ИС
больниц
консульта
нт по ИС
здравоох
ранения,
Руководи
тель
команды
экспертов
Эксперт
по
управлен
ию
управления информации здравоохранения для ПМСП; Разработка пожизненных
медицинских записей для больниц и пилотирование БД для 8 районов и 3 провинций;
подготовка национального внедрения; определение требований к аппаратному и программному
обеспечению на основе международных стандартов. Разработка 10 картированных таблиц ICD
и формат отчетности. Организация семинаров по HIM, управлению изменениями, контролю
качества, систем медицинских записей и статистики
Внешний аудитор по системам качества (примерно 5 раз в год) в частных и общественных
больницах и на дому для пожилых людей; оценка соответствия требованиям сертификата
качества TÜVQualityCertificationISO 9001:2000 и EFQM. Завершено в 2006.
Первый аудит качества по обновлению сертификата управления качеством на амбулаторной
уровне в германии а так же при лечении на дому.
Краткосрочный консультант для МЗ Сирии по подготовке тендерных документов по ИС
больниц для 3 больниц (Дамаск, Дараа и Латаккиа: 500, 350, 200 коек) в Сирии: анализ
бизнес процессов (клинические, административные), информационной структуре и отчетности;
Определение функциональных требований для ИС больниц; разработка обучающей программы
на 200 слушателей (9 месяцев программа); разработка расчета затрат на начальные
инвестиции, обучение, последующая техническая поддержка ПО и оборудования.
Поддержка МЗ по реорганизации и обновлению ИС здравоохранения включая:
Hархитектуру ИС здравоохранения; управление информацией; закуп и обучение в мед
учреждении, институте общественного здравоохранения и МЗ, финансируется EAR:
SCRE/111164/D/S/KOS и 01/KOS01/10/002
Серия краткосрочный миссий в целях поддержки управления больниц по реализации системы
управления качеством, с фокусом на амбулаторное управление, пациентов и рабочего потока,
инфраструктуру, и управление медицинскими отходами. Обучение по внутреннему аудиту,
анализу рисков, управлению изменениями; утилизация отходов и опасного инвентаря и
система раннего предупреждения о рисках (на основе WasteCatalogueOrdinance 91/689/EEC,
Директива ЕС по опасным отходам).
11.20
04
Вьетнам
Винх
05.20
03 11.20
04
Вьетнам
02.20
02
07.02
Албания
10.20
01
01.20
02
Косово
09.20
00
09.20
01
10.19
92
–
09.20
00
Косово
ХоШиМ
ин
Байрам
кури
Пристин
а
Призрен
Германи
я
Кемптен
.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/0204Dr Hristos
Dagres
hdagres@gmail.com
Bernard Brunhes
International
Dr Matthias Reinicke
European Agency for
Reconstruction Task
Manager Health
mwreinicke@googlema
il.com
Kinderberg
International
Dr Uke Paloke Prizren
Contact data in search
консульт
ант по
ИС
здравоох
ранения
Консульт
ант по
обучени
ю
UniversityTeachingHos
pital (650 beds)Renate
Barn-steiner
renate.barnsteiner@klin
ikum-kempten.de
Заместит
ель
директор
а по
сестринск
Медицин
ский
координа
тор
Оценка клинических, управленческих и ИТ услуг для региональной педиатрической больницы
(350-коек) (VinhNgheAnProvince) в контексте аудита качества. Анализ процесса менеджмента,
анализ подготовленности к ЧС и обучение, семинары по внедрению международных
стандартов управления качеством ISO 9001/2000 и процессов сертификации ISO.
СериякраткосрочныймиссийвгородаAn Giang Province, Ba Rja Veng Tan Provinceи Ho Chi Minh,
Вьетнама.
Разработка плана действий на 5 лет для МЗ по реализации всесторонней амбулаторной
системы; анализ потребностей в обучении для персонала больниц; проведение тренинга по
менеджменту для менеджеров среднего уровня; внедрение международных стандартов ISO
9001:2000; обучение менеджеров больниц методам расчета персонала на основе индикаторов
эффективности; внедрение системы ухода за пациентами и документации.
Реализация системы управления информации больницы. Определение требований к БД;
поддержка и надзор на локальной разработкой БД; реорганизация архива больниц и внедрение
систем их заполнения; оценка качество услуг в провинциальной больнице.
Обучение персонала и менеджеров больниц и учреждений здравоохранения (300 участников
курсов, из 70 объектов), всех медицинских учреждений Косово; Разработка описания работы и
рабочего места, методы наблюдения рабочего потока в медицинских учреждениях; контроля
качества и управления качеством; Финансируется EAR: EuropeAid/117556/D/SV/KOS
Региональная больница на 660 коек, реализация интегрированной системы амбулаторной
документации, оценка потребностей и организация подготовленности к ЧС,
усовершенствование управления больницами, услуги для педиатрического отделения.
Подготовка технических спецификаций на закуп оборудования, реконструкция отделений,
пола, санитарных отделений; надзор над работами.
Координация 2 вновь созданных местных больниц по вопросам операционных условий;
постоянная административная ответственность за 160 человек отделения, и в качестве
заместителя за 600 человек мед персонала: планирование персонала и бюджетирование на
основе индикаторов эффективности согласно законодательству в области медицины и
страхованию. Председатель комитета по оценке и планированию ИТ по реализации новых
04.19
90
04.91
01.19
88
03.90
08.19
86
09.87
Германи
я
Кауфбер
ен
Германи
я
Кауфбер
ен
Уганда
Юмбе
04.19
85
07.19
86
Германи
я
Фессен
02.19
8403.85
Германи
я
Мюнхен
University Hospital
Marchioninistraße 15
Tel. 089/7095-0
09.19
82
09.85
Германи
я
Кауфбер
ен
RedCrossEmergencySe
rviceManagingdirectort
homas.hofmann@kvost
allgaeu.brk.de
District Hospital
Nursing director
Harald.keller@bkhkaufbeuren.de
District Hospital
Nursing director
Harald.keller@bkhkaufbeuren.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
ой
службе
Ассистен
т лектора
рабочих графиков. Внедрение системы обеспечения качества по стандартам клинической
службы; координация и анализ пробелов.
Школа медсестер Кауфберен: лектор по общей медсестринской службе. Исследование
медицинской информации. Практическое обучение для студентов.
Глава
сестринс
кой
службы
Зарегист
рированн
ая
медсестр
а
Районная больница Кауфберен (700 коек): планирование персонала. Планирование
реконструкции и инвестиций. Управление ежедневной работой районной мужской больницей
острых психиатрических заболеваний (35-коек)
Медсестр
ав
операцио
нной и
отделени
и
интенсив
ной
терапии
Медсестр
ав
отделени
и
интенсив
ной
терапии
Медтехн
ик
скорой
помощи
5 операционных кабинетов: ежедневная работа с хирургическим и гинекологическим
оборудованием, анестезии и реанимации. Обязанности по технической поддержке
оборудования по анестезии и аварийному оборудованию.
Поддержка больнице в 100 коек в условиях гражданской войны. Медицинская служба в лагере
беженцев UNHCR при чрезвычайных обстоятельствах. Обучение медицинского персонала по
вопросам гигиены. Разработка проколов лечения.
Больница при университете Мюнхена (1200 коек): кардио -хирургическое отделение
интенсивной терапии – 10 коек. Член команды по трансплантации сердца.
Глава полностью экипированного автомобиля скорой помощи и средств интенсивной терапии.
Тренер по процедурам реанимации; специальная лицензия на вождение автомобиля скорой
помощи; добровольная работа по ночам, свободные дни.
09.19
82
02.84
Германи
я
Marktoberdorf
Regional Hospital
Elke.Rieger@klinikenoal-kf.de
Общая
медсестр
а
Региональная больница Marktoberdorf (250 коек): отделение интенсивной терапии на 5 коек,
общий уход за пациентами в хирургическом отделении и отделении внутренних органов
Раздел III. Правомочность стран
7
15. другая соответствующая информация
(например публикации):
ВОЗ сетевой доступ к HINARI онлайн медицинской библиотеке
для областной больницы Мазари-Шариф.
2009
Ко-модератор поддержки афганских участников телемедицины сетевого
сервера Базельского университета для теле-патоморфологического
сотрудничества
2003
Преподаватель экономического факультета Приштине, семинар MBA
управления в области общественного здравоохранения по
Информационным системам здравоохранения
2004
Лектор на медицинском факультете ХоШиМин по управлению
информацией больницы
1997/1999
Преподаватель СТТ- Академия Трир / Вайскирхен по: расчету
персонала, планирование и управление персоналом в больницах и домах
престарелых; подготовка и проведение процессов управления
изменениями
1997/1998
Наставничество для страны - Уганды в программе ASA, программы
обмена молодыми специалистами и студентами, основанные германским
министерством иностранных дел.
1994/1998
член комитета работников больницы
1993/1998
Лектор в Мюнхенском центре непрерывного профессионального
образования по администрации больницы и управленческой экономике
для менеджеров дома престарелых и руководителей амбулаторных
организаций и по расчету персонала с использованием различных
показателей.
1979/2004
Член Германского трудового совета по общественному сектору.
2009
Публикации/выступления (автор/со-автор):
2012
NATOAdvancedResearchWorkshop: Кабул "Создание осведомленности для
использования систем OpenSource в государственном секторе в Афганистане”
2009 “Раннее тестирование удовлетворенности пользователей. После выполнения
системы Центральных электронных медицинских записей (ЭМК) Сербии "Журнал по
информационным технологиям в здравоохранении 2009 года; 7 (2)
2009 “Взаимодействие, интеграция и управление рисками в создании электронных
медицинских записей: подход Сербии "
Журнал по информационным технологиям в здравоохранении Том 7 Выпуск 2 2009
2009 “Планирование новой больницы в Афганистане, баланс между каменным веком
и высокими технологиями 21-го века "
НАТО региональное командование Международными силами содействия
безопасности (МССБ) - Лагерь Marmal Афганистан
Раздел III. Правомочность стран
8
2008 “Электронные медицинские записи в Сербии, проект финансируемый ЕС дает
результаты, более широкий интерес ", Европа 5/2008
2008 “Подход и риски взаимодействия ЭМК и интеграции с системами ИКТ,
наследие здравоохранения "6-я ICICTH Конференция Остров Самос – Греция
2008 “Разработка и внедрение центральных электронных медицинских записей в
Сербии: Ранняя стадия испытания, удовлетворение пользователей" шестой ICICTH
конференция Остров Самос – Греция
2008 “Электронные медицинские записи - Возможности для будущего в системе
здравоохранения Сербии ", Национальная конференция по Электронным медицинским
записям, Белград – Сербия
2008 “Электронные медицинские карты - Что можно сделать с ними для системы
подушевого норматива"Национальная конференция по системе подушевого
норматива, Европейское агентство по реконструкции, Белград-Сербия
2007 “Развитие информационной системы здравоохранения в сельской местности в
Индонезии "Национальная конференции по медицинской информации Системы SCHS
проекта Джакарта – Индонезия
2006 “Аутсорсинг Информационные системы здравоохранения, один вариант для
развивающихся стран ". 4-й ICICTH конференция Самос Остров – Греция
2001 “Как телемедицина может способствовать стабилизации Юго-ВосточнойЕвропы ". Американский Телемедицина Ассоциация - Форт-Лодердейл – США
1998 “Правовые последствия осуществления протоколов для ухода за пациентами в
больницах”. “Клиник инфо” Бавария, Германия.
Michael Weinhara
Раздел III. Правомочность стран
9
РАЗДЕЛ III. ПРАВОМОЧНОСТЬ СТРАН ДЛЯ
ПРЕДОСТАВЛЕНИЕ ТОВАРОВ, РАБОТ И УСЛУГ В РАМКАХ
ЗАКУПОК, ФИНАНСИРУЕМЫХ БАНКОМ
Правомочность стран на предоставление Товаров, Работ и Услуг в
рамках закупок, финансируемых Банком
По состоянию на сентябрь 2007
1.
Фирмы и товары всех стран правомочны для участия в данном конкурсе кроме
стран, указанных в данном списке.
2
В соответствии с параграфом 1.8 (а) Руководства «Закупки по займам МБРР и
кредитам МАР», датированная 24 мая 2004, фирмы или товары могут быть исключены,
если они зарегистрированы или проведены в странах:
(i)
с которыми, в соответствии с законом или официальным распоряжением
страна Заемщика запрещает вступать в коммерческие отношения, при
условии, что Банк согласен, что такой запрет не препятствует эффективной
конкуренции за поставку товаров или производство работ, или
(ii) из которых, в соответствии с решением Совета Безопасности ООН,
принятом в соответствии с ГлавойVII Устава ООН, страна Заемщика
запрещает импорт товаров, а также производство платежей в адрес
физических или юридических лиц.
3.
К сведению Заемщиков и Участников торгов, в настоящее время фирмы, товары
и услуги исключаются для данной закупки, если они происходят из следующих стран:
В соответствии с параграфом 1.8 (a) (i):
Нет
В соответствии с параграфом 1.8 (a) (ii):
Нет
Раздел IV. Общие условия контракта
10
РАЗДЕЛ IV. ОБЩИЕ УСЛОВИЯ КОНТРАКТА
Перечень статей
A. Контракт и его толкование ..........................................................................................12
1.
2.
3.
4.
5.
6.
Определения ............................................................................................................12
Контрактная документация ....................................................................................22
Интерпретация ........................................................................................................22
Уведомления............................................................................................................25
Регулирующее право ..............................................................................................26
Урегулирование споров ..........................................................................................26
B. Предмет Контракта........................................................................................................29
7.
8.
9.
10.
Состав Системы ......................................................................................................29
Сроки начала работ и Приемки Системы в эксплуатацию .................................30
Обязанности Поставщика ......................................................................................31
Обязанности Покупателя .......................................................................................33
C. Платеж..............................................................................................................................35
11.
12.
13.
14.
Цена контракта ........................................................................................................35
Условия платежа .....................................................................................................35
Обеспечение ............................................................................................................36
Налоги и пошлины ..................................................................................................37
D. Интеллектуальная собственность ..............................................................................39
15.
16.
17.
Авторские права ......................................................................................................39
Лицензии на Программные продукты ..................................................................40
Конфиденциальная информация ...........................................................................42
E. Поставка, установка, тестирование, ввод в эксплуатацию и приемка Системы44
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
Представители .........................................................................................................44
План проекта ...........................................................................................................47
Заключение договоров субподряда .......................................................................47
Проектно-конструк-торская документация..........................................................49
Закупка, поставка и транспортировка ...................................................................52
Модернизация продукции ......................................................................................54
Реализация, установка и прочие услуги ...............................................................56
Инспекция и тестирование .....................................................................................56
Установка Системы ................................................................................................57
Ввод и Приемка в эксплуатацию ..........................................................................59
Раздел IV. Общие условия контракта
11
F. Гарантии и ответственность ........................................................................................63
28.
29.
30.
31.
32.
33.
Гарантия соблюдения сроков Приемки в эксплуатацию ....................................63
Ответствен-ность за дефекты ................................................................................65
Функцио-нальные гарантии ...................................................................................68
Гарантия соблюдения Прав интеллектуальной собственности .........................69
Возмещение ущерба от нарушения Прав интеллектуальной собственности ...69
Пределы ответственности ......................................................................................73
G. Распределение рисков ...................................................................................................73
34.
35.
36.
37.
38.
Передача прав собственности ................................................................................73
Уход за Системой....................................................................................................74
Утрата или повреждение имущества; несчастный случай или травма на
производстве; возмещение ущерба .......................................................................75
Страхование.............................................................................................................78
Форс-мажор .............................................................................................................80
H. Изменение компонентов Контракта ..........................................................................82
39.
40.
41.
42.
Изменение Системы ...............................................................................................82
Перенос Даты приемки в эксплуатацию на более поздний срок .......................87
Расторжение Контракта..........................................................................................88
Цессия ......................................................................................................................98
Раздел IV. Общие условия контракта
12
Общие условия контракта
A. КОНТРАКТ И ЕГО ТОЛКОВАНИЕ
1. Определения
1.1
В настоящем Контракте приведенные ниже термины
интерпретируются следующим образом.
(a) компоненты контракта
(i) “Контракт” означает Контрактный договор
между Покупателем и Поставщиком вместе с
упомянутой
в
нем
Контрактной
документацией. Контрактный договор и
Контрактная
документация
составляют
Контракт, и термин “Контракт” подлежит
соответствующему толкованию во всех
указанных документах.
(ii) “Контрактная
документация”
означает
документы, перечисленные в Статье 1.1
(Контрактная
документация)
Формы
Контрактного соглашения (включая все
поправки, внесенные в эти документы).
(iii) “Контрактное соглашение” означает договор
между Покупателем
и
Поставщиком,
заключенный по Форме Контрактного
соглашения,
приведенной
в
разделе
“Образцы форм” Документации для торгов,
включая любые поправки к этой форме,
согласованные Покупателем и Поставщиком.
Дата Контрактного соглашения должна быть
указана в подписанной форме.
(iv) “ОУК” означает Общие условия контракта.
(v) “СУК” означает Специальные условия
контракта.
(vi) “Технические требования” означает раздел
“Технические требования” Документации
для торгов.
(vii) “График реализации” означает подраздел
“График реализации” в разделе “Технические
требования”.
viii) “Цена контракта” означает цену или цены,
указанные в Статье 2 Контрактного
соглашения (Цена контракта и условия
платежа).
(ix) “Руководство
по
закупкам”
означает
указанное в СУК издание Руководства
Всемирного банка “Закупки по займам МБРР
Раздел IV. Общие условия контракта
13
и кредитам МАР”.
(x)
(b)
“Документация
для
торгов”
означает
комплект
документов,
выпущенных
Покупателем в качестве инструкций и
источника информации для потенциальных
Поставщиков в том, что касается процедур
проведения конкурсных торгов, отбора
победителя и составления Контракта, а также
контрактных
условий,
регулирующих
отношения
между
Покупателем
и
Поставщиком. Общие и Специальные
условия контракта, Технические требования
и все прочие документы в составе
Документации
для
торгов
отражают
положения Руководства Всемирного банка по
закупкам, которые Покупатель обязан
соблюдать в процессе закупок и ведения
настоящего Контракта.
юридические и физические лица
(i)
“Покупатель” означает указанную в СУК
организацию, осуществляющую закупку
Информационной системы.
(ii)
“Директор
проекта”
означает
лицо,
названное так в СУК или иным образом
назначенное Покупателем так, как это
предусмотрено в Статье 18.1 ОУК (Директор
проекта), и призванное выполнять в этом
качестве обязанности, делегированные ему
Покупателем.
(iii) “Поставщик”
означает
фирму
или
Совместное предприятие, чье предложение о
выполнении
Контракта
принято
Покупателем, и указанную в этом качестве в
Контрактном соглашении.
(iv) “Представитель Поставщика” означает любое
лицо, назначенное Поставщиком, упомянутое
в этом качестве в Контрактном соглашении
или
иным
образом
утвержденное
Покупателем для выполнения обязанностей,
делегированных ему Поставщиком, так, как
это предусмотрено в Статье 18.2 ОУК
(Представитель Поставщика).
Раздел IV. Общие условия контракта
14
(v)
“Субподрядчик”, означает любую фирму,
которой Поставщик – прямо или косвенно –
дает субподряд на выполнение каких-либо
обязанностей
Поставщика,
включая
подготовку любых чертежей или поставку
любых Информационных технологий или
иных Товаров или Услуг.
(vi) “Третейский судья” означает лицо, указанное
в
Приложении
2
к
Контрактному
соглашению и, по соглашению между
Покупателем и Поставщиком, назначенное
для принятия решения или урегулирования
спора между Покупателем и Поставщиком, с
которым стороны обратились к нему или к
ней в соответствии со Статьей 6.1 ОУК
(Третейский суд).
(vii) “Всемирный банк” (также именуемый
“Банк”) означает Международный банк
реконструкции и развития (МБРР) или
Международную
ассоциацию
развития
(МАР).
(c)
состав
(i)
“Информационная
система”
(также
именуемая
“Система”)
означает
все
Информационные технологии, Материалы и
прочие Товары, которые должны быть
поставлены, установлены, интегрированы и
введены в эксплуатацию (за исключением
Оборудования Поставщика), а также Услуги,
которые Поставщик должен предоставить на
основании Контракта.
(ii)
“Подсистема” означает любую часть
Системы, определенную в этом качестве в
самом Контракте, которая может быть
отдельно
поставлена,
установлена,
протестирована и введена в эксплуатацию
до Ввода в эксплуатацию всей Системы.
(iii)
“Информационные технологии” означает
все оборудование для обработки данных и
передачи
информации,
Программные
продукты, сырье и расходные материалы,
которые Поставщик должен поставить и
Раздел IV. Общие условия контракта
15
установить в соответствии с Контрактом.
(iv)
“Товары” означает все оборудование,
технику, принадлежности, Материалы и
прочие предметы, которые Поставщик
должен поставить или поставить и
установить в соответствии с Контрактом,
включая,
без
ограничения
нижеперечисленным,
Информационные
технологии и Материалы, но исключая
Оборудование Поставщика.
(v)
“Услуги”
означает
все
технические,
организационные, управленческие и прочие
Услуги, которые Поставщик должен
предоставить в соответствии с Контрактом в
целях поставки, установки, кастомизации и
интеграции Системы и ее ввода в
эксплуатацию. В состав таких Услуг могут
входить,
среди
прочего,
управление
деятельностью и обеспечение качества,
проектирование, разработка, кастомизация,
составление
документации,
транспортировка, страхование, проведение
инспекции,
экспедиторские
услуги,
подготовка
площадки,
установка,
интеграция, обучение персонала, миграция
данных,
Подготовка
к
вводу
в
эксплуатацию, Ввод в эксплуатацию,
техническое обслуживание и техническая
поддержка.
(vi)
“План проекта” означает документ, который
в соответствии со Статьей 19 ОУК должен
быть разработан Поставщиком и одобрен
Покупателем
с
учетом
требований
Контракта и Предварительного плана
проекта, включенного в состав конкурсного
предложения Поставщика. “Согласованный
и уточненный план проекта” – это вариант
Плана проекта, одобренный Покупателем в
соответствии со Статьей 19.2 ОУК. В случае
каких-либо противоречий между Планом
проекта и Контрактом преимущественную
силу имеют соответствующие положения
Контракта, включая любые поправки к нему.
(vii) “Программный продукт” означает часть
Раздел IV. Общие условия контракта
16
Системы в форме команд, благодаря
которым Подсистемы, обеспечивающие
обработку
данных,
функционируют
определенным образом или выполняют
определенные операции.
(viii) “Системный
программный
продукт”
означает Программный продукт, который
дает операционные и управленческие
команды базовому оборудованию и другим
элементам и определен как таковой в
Приложении 4 к Контрактному соглашению,
а также другие Программные продукты,
которые
на
основании
письменной
договоренности
сторон
могут
быть
определены как Системные программные
продукты. К числу таких Системных
программных продуктов относятся, среди
прочего, встроенные микропрограммы (т.е.
программы,
записанные
в
ПЗУ),
операционные
системы,
программы
передачи данных, программы координации
работы системы и сети, а также утилиты.
(ix)
“Универсальный программный продукт”
означает Программный продукт, который
поддерживает общее делопроизводство и
общие
операции
по
разработке
программного обеспечения и определен как
таковой в Приложении 4 к Контрактному
соглашению, а также другие Программные
продукты,
которые
на
основании
письменной договоренности сторон могут
быть определены как Универсальные
программные продукты. К числу таких
Универсальных программных продуктов
относятся,
среди
прочего,
системы
подготовки текстов, электронные таблицы,
общие программы управления базами
данных
и
программы
разработки
приложений.
(x)
“Прикладной
программный
продукт”
означает Программный продукт, который
предназначен для выполнения специальных
коммерческих или технических функций и
взаимодействия с коммерческими или
Раздел IV. Общие условия контракта
17
техническими пользователями Системы и
определен как таковой в Приложении 4 к
Контрактному соглашению, а также другие
Программные продукты, которые на
основании письменной договоренности
сторон могут быть определены как
Прикладные программные продукты.
(xi)
“Стандартный
программный
продукт”
означает Программный продукт, который
определен как таковой в Приложении 4 к
Контрактному соглашению, а также другие
Программные продукты, которые на
основании письменной договоренности
сторон могут быть определены как
Стандартные программные продукты.
(xii) “Кастомизированный
программный
продукт” означает Программный продукт,
который определен как таковой в
Приложении 4 к Контрактному соглашению,
а также другие Программные продукты,
которые
на
основании
письменной
договоренности
сторон
могут
быть
определены
как
Кастомизированные
программные продукты.
(xiii) “Исходный текст” означает структуры баз
данных, словари, определения, тексты
программ,
а
также
любые
другие
символические представления, необходимые
для
компиляции,
использования
и
последующего поддержания Программных
продуктов (как правило, нужен для
Кастомизированных
программных
продуктов, хотя не только для них).
(xiv) “Материалы” означает всю документацию в
печатном или готовом для печати виде, все
виды руководств и информационных
пособий (включая аудио, видео и текстовые
материалы)
на
любых
носителях,
предоставленные Покупателю в рамках
Контракта.
(xv) “Стандартные материалы” означает все
Материалы, не отнесенные к категории
Кастомизированных.
Раздел IV. Общие условия контракта
18
(xvi) “Кастомизированные материалы” означает
Материалы, которые Поставщик разработал
в рамках Контракта за счет Покупателя и
которые определены как таковые в
Приложении 5 к Контрактному соглашению,
а также другие Материалы, которые на
основании письменной договоренности
сторон могут быть определены как
Кастомизированные материалы. К числу
Кастомизированных
относятся
также
Материалы,
созданные
на
основе
Стандартных материалов.
(xvii) “Права интеллектуальной собственности”
означает любое и все авторские права,
моральные права, торговые марки, патенты
и
прочие
интеллектуальные
и
имущественные права, титулы и интересы в
разных
странах
мира
(будь-то
законодательно закрепленные, условные или
будущие), включая, без ограничения
нижеперечисленным, все экономические и
все
эксклюзивные
права
на
воспроизведение, исправление, адаптацию,
модификацию,
перевод,
создание
производных продуктов, извлечение или
повторное
использование
данных,
изготовление,
пуск
в
обращение,
публикацию, распространение, продажу,
лицензирование,
сублицензирование,
уступку, аренду, сдачу в аренду, передачу
по электронным каналам связи или
предоставление
электронного
доступа,
передачу в виде сообщений, ввод в память
компьютера или иное использование любой
части или копии, полностью или частично, в
любой форме, прямо или косвенно, или
право выдавать разрешение или передавать
полномочия
другим
лицам
на
осуществление вышеперечисленного.
(xviii) “Оборудование Поставщика” означает все
оборудование, инструменты, аппаратуру
или разного рода предметы, необходимые в
процессе или для установки, завершения и
технического
обслуживания
Системы,
которые должны быть предоставлены
Раздел IV. Общие условия контракта
19
Поставщиком, исключая Информационные
технологии и иные позиции, входящие в
состав Системы.
(d)
виды деятельности
(i) “Доставка” означает передачу Товаров от
Поставщика Покупателю в соответствии с
последним
изданием
ИНКОТЕРМС,
указанным в Контракте.
(ii) “Установка” означает, что указанная в
Контракте Система или Подсистема готова к
Вводу
в
эксплуатацию,
как
это
предусмотрено в Статье 26 ОУК (Установка).
(iii) “Подготовка к вводу в эксплуатацию”
означает тестирование, проверку и принятие
всех
прочих
необходимых
мер,
перечисленных в разделе “Технические
требования”, которые должны быть приняты
Поставщиком в процессе подготовки к Вводу
Системы
в
эксплуатацию,
как
это
предусмотрено в Статье 26 ОУК (Установка).
(iv) “Ввод
в
эксплуатацию”
означает
использование
Системы
или
любой
Подсистемы Поставщиком после завершения
Установки так, как это предусмотрено в
Статье 27.1 ОУК (Ввод в эксплуатацию), в
целях проведения Приемочных испытаний.
(v) “Приемочные
испытания”
означают
испытания,
перечисленные
в
разделе
“Технические требования”, а также в
Согласованном и уточненном плане проекта,
которые проводятся в целях подтверждения
того,
что
Система
или
конкретная
Подсистема может обеспечить выполнение
функциональных
и
эксплуатационных
требований, перечисленных в разделе
“Технические требования”, а также в
Согласованном и уточненном плане проекта,
как это предусмотрено в Статье 27.2 ОУК
(Приемочные испытания).
(vi) “Приемка в эксплуатацию” означает приемку
Покупателем всей Системы (или любой
Подсистемы (Подсистем), если Контракт
предусматривает приемку Системы по
частям) в соответствии со Статьей 27.3 ОУК
(Приемка в эксплуатацию).
Раздел IV. Общие условия контракта
(e)
20
время и место
(i)
“Страна Покупателя”
указанная в СУК.
–
это
страна,
(ii)
“Страна Поставщика” – это страна, на
территории которой Поставщик создан как
юридическое лицо и которая указана в
Контрактном соглашении.
(iii)
“Проектная площадка (площадки)” означает
указанное в СУК место (места) для поставки
и установки Системы.
(iv) “Правомочная страна” означает страны и
территории, имеющие право на участие в
закупках,
финансируемых
Всемирным
банком, как это определено в Руководстве
“Закупки по займам МБРР и кредитам МАР”.
(Примечание: Всемирный банк ведет список
стран, являющихся странами происхождения
Участников торгов, Товаров и Услуг,
которые не могут принимать участие в
закупках, финансируемых Банком. Этот
список регулярно обновляется и его можно
получить
в
Центре
общественной
информации Банка или на сайте Центра,
посвященном вопросам закупок. Перечень
стран, не имеющих права участия в закупках,
финансируемых Банком, приведен разделе
Документации для торгов “Право на
предоставление Товаров, Работ и Услуг в
рамках закупок, финансируемых Банком ”).
(v)
“День”
означает
календарный
грегорианского календаря.
день
(vi) “Неделя”
означает
семь
(7)
последовательных Дней, начиная со дня,
который принято считать началом недели в
Стране Покупателя.
(vii) “Месяц” означает календарный
грегорианского календаря.
месяц
(viii) “Год”
означает
двенадцать
последовательных Месяцев.
(12)
(ix) “Дата вступления в силу” означает дату
выполнения всех условий, перечисленных в
Раздел IV. Общие условия контракта
21
Статье
3
Контрактного
соглашения
(Фактическая дата определения момента
Приемки в эксплуатацию), для целей
определения сроков Доставки, Установки и
Приемки в эксплуатацию Системы или
Подсистемы (Подсистем).
(x)
“Период действия Контракта” – это период
времени, в течение которого настоящий
Контракт
определяет
отношения
и
обязанности Покупателя и Поставщика в
связи с Системой, как это указано в СУК.
(xi) “Период ответственности за дефекты” (также
именуемый “Гарантийный период”) означает
период действия гарантий, выданных
Поставщиком, начиная со дня подписания
Акта эксплуатационной приемки Системы
или Подсистемы (Подсистем), в течение
которого Поставщик несет ответственность
за дефекты Системы (или соответствующей
Подсистемы
(Подсистем)),
как
это
предусмотрено
в
Статье
29
ОУК
(Ответственность за дефекты).
(xii) “Период послегарантийного обслуживания”
означает указанное в СУК число лет (если
этот период предусмотрен) после окончания
Гарантийного периода, в течение которых на
Поставщика
может
быть
возложена
обязанность предоставить лицензии на
Программные продукты и осуществлять
техническое
обслуживание
и/или
техническую поддержку Системы либо в
рамках настоящего Контракта, либо на
основании отдельного контракта (отдельных
контрактов).
(xiii) “Период действия” означает Дни Недели и
часы в такие Дни Недели, когда должны
предоставляться услуги по техническому
обслуживанию,
эксплуатации
и/или
технической поддержке (если таковые
предусмотрены).
Раздел IV. Общие условия контракта
2. Контрактная
документация
2.1
3. Интерпретация
3.1
22
С учетом положений Статьи 1.2 Контрактного
соглашения (Порядок старшинства) все документы,
входящие в состав Контракта, (а также все части этих
документов) должны соотноситься друг с другом,
дополнять и пояснять друг друга. К Контракту следует
подходить как к единому целому.
Язык
3.1.1 Вся
Контрактная
документация,
вся
корреспонденция и все сообщения, которые
подлежат отправке, должны быть написаны на
языке, указанном в СУК, а Контракт подлежит
толкованию и интерпретации в соответствии с
этим языком.
3.1.2 Если какой-либо документ в составе Контрактной
документации, какая-либо корреспонденция или
сообщение составлены на языке, который не
является регулирующим языком в соответствии со
Статьей 3.1.1 ОУК, преимущественную силу в
вопросах интерпретации имеет перевод такого
документа, корреспонденции или сообщения.
Расходы на такой перевод и связанные с ним
риски берет на себя сторона, являющаяся
составителем этого документа, корреспонденции
или сообщения.
3.2
Единственное и множественное число
Единственное
число
подразумевает
также
множественное
число,
а
множественное
–
единственное, за исключением случаев, где контекст
требует иного.
3.3
Заголовки
Заголовки и заметки на полях в Общих условиях
контракта приведены для удобства ссылки; они не
являются частью Контракта и не влияют на его
интерпретацию.
3.4
Лица
Слова, означающие лиц или стороны, относятся также к
фирмам, корпорациям и государственным ведомствам.
3.5
ИНКОТЕРМС
За исключением случаев, когда это противоречит
Раздел IV. Общие условия контракта
23
какому-либо положению Контракта, значение любого
коммерческого термина, а также права и обязанности
сторон Контракта соответствуют тому, что указано в
действующем издании ИНКОТЕРМС (“ИНКОТЕРМС
2000” или более поздняя версия, если и как только она
будет
опубликована).
ИНКОТЕРМС
–
это
международные правила толкования коммерческих
терминов, публикуемые Международной торговой
палатой (38 CoursAlbert 1er, 75008 Paris, France).
3.6
Всеобъемлющее соглашение
Контракт
представляет
собой
всеобъемлющее
соглашение между Покупателем и Поставщиком
относительно предмета Контракта и заменяет все
контакты, переговоры и договоренности (будь-то
письменные
или
устные)
между
сторонами,
касающиеся предмета Контракта, которые имели место
до дня подписания Контракта.
3.7
Поправки
Все поправки или иные изменения Контракта
действительны только в том случае, если они
выполнены в письменном виде, датированы, имеют
четкую
ссылку
на
Контракт
и
подписаны
представителем каждой стороны Контракта, имеющим
надлежащие полномочия.
3.8
Независимый Поставщик
Поставщик является независимым подрядчиком,
выполняющим Контракт. Контракт не создает между
сторонами
Контракта
никакой
организации,
товарищества, совместного предприятия или иных
совместных отношений.
С учетом положений Контракта Поставщик несет
единоличную ответственность за то, каким образом
выполняется Контракт. Все сотрудники, представители
или Субподрядчики Поставщика, привлеченные для
выполнения Контракта, находятся под полным
контролем Поставщика и не считаются сотрудниками
Покупателя, и ничто в настоящем Контракте или любом
договоре субподряда, который заключил Поставщик, не
должно толковаться как формирование каких-либо
договорных отношений между такими сотрудниками,
представителями
или
Субподрядчиками
и
Раздел IV. Общие условия контракта
24
Покупателем.
3.9
Совместное предприятие или Консорциум
Если Поставщик является Совместным предприятием
или Консорциумом, в состав которого входят два или
несколько фирм, все эти фирмы должны нести
индивидуальную и солидарную ответственность перед
Покупателем за выполнение положений Контракта и
назначают одно из таких лиц головной организацией,
имеющей право принимать обязательства от имени
Совместного предприятия или Консорциума. Состав и
структура Совместного предприятия или Консорциума
не подлежат изменению без предварительного согласия
Покупателя.
3.10 Отказ от прав
3.10.1 С учетом положений Статьи 3.10.2 ОУК, если
одна из сторон освобождает другую сторону,
отказывается от принятия или задерживает
принятие мер по отношению к другой стороне
или дает ей отсрочку в том, что касается
выполнения какого-либо условия Контракта или
предоставления необходимого времени, это
никак не ущемляет, не умаляет и не
ограничивает ее прав по Контракту, а отказ
одной из сторон от применения санкций за
какое-либо нарушение Контракта не является
отказом от применения санкций в случае любого
последующего
или
продолжающегося
нарушения Контракта.
3.10.2 Отказ любой из сторон от своих прав,
полномочий или санкций в рамках Контракта
должен быть оформлен в письменном виде,
датирован
и
подписан
полномочным
представителем отказывающейся стороны; в нем
также должно быть указано, от какого права и в
каком объеме отказывается эта сторона.
3.11 Делимость Контракта
Если какое-либо положение или условие Контракта
подпадает под запрет или теряет силу или возможность
принудительного осуществления, то такой запрет или
утрата силы или возможности принудительного
осуществления не оказывают никакого влияния на
Раздел IV. Общие условия контракта
25
юридическую силу или возможность принудительного
осуществления прочих положений и условий
Контракта.
3.12 Страна происхождения
“Происхождение”
означает
место,
где
были
произведены Информационные технологии, Материалы
и прочие Товары, предназначенные для нужд Системы,
или место, откуда предоставляются Услуги. Товары
считаются произведенными, когда в результате
изготовления, переработки, разработки Программных
продуктов или существенной и крупномасштабной
сборки или интеграции составных частей получается
коммерчески
признанный
продукт,
значительно
отличающийся
по
основным
характеристикам,
назначению или способу применения от своих составных
частей. Происхождение Товаров и Услуг не идентично
национальной принадлежности Поставщика и может
отличаться от нее.
4. Уведомления
4.1
Если в Контракте нет иных указаний, все уведомления,
которые должны быть направлены в рамках Контракта,
оформляются в письменном виде и доставляются, как
указано в Статье 4.3 ОУК, лично либо отправляются
авиапочтой или специальной курьерской почтой, либо
передаются как каблограмма или телеграмма, либо
отправляются по телексу, телефаксу, электронной почте
или системе электронного обмена информацией (ЭОИ),
с соблюдением перечисленных далее условий.
4.1.1 Любое уведомление, отправленное в виде
каблограммы, телеграммы, телекса, факса,
сообщения, переданного по электронной почте
или системе ЭОИ, в течение двух (2) дней после
отправки
подтверждается
уведомлением,
отправленным авиапочтой или специальной
курьерской почтой, за исключением тех случаев,
когда Контракт предусматривает иное.
4.1.2 Любое уведомление, отправленное авиапочтой
или специальной курьерской почтой, считается
доставленным через десять (10) дней после
отправки (если нет доказательств более ранней
доставки). В подтверждение факта отправки
достаточно продемонстрировать, что на конверте,
где находилось уведомление, был указан
правильный адрес, что он был проштемпелеван и
Раздел IV. Общие условия контракта
26
передан органу почтовой связи или курьерской
службе
для
пересылки
авиапочтой
или
специальной курьерской почтой.
4.1.3 Любое уведомление, доставленное лично или
отправленное в виде каблограммы, телеграммы,
телекса, факса, сообщения, переданного по
электронной почте или системе ЭОИ, считается
доставленным в день отправки.
4.1.4 Каждая из сторон может сменить свой почтовый,
телеграфный, телексный или факсимильный адрес,
адрес электронной почты или адрес в системе
ЭОИ для получения таких уведомлений, направив
второй стороне соответствующее письменное
уведомление за десять (10) дней до такой смены.
4.2
Считается, что уведомления содержат любые санкции,
разрешения, инструкции, поручения, сертификаты,
информацию и другие сведения, которые даются в
рамках Контракта.
4.3
В соответствии со Статьей 18 ОУК, уведомления в
адрес Покупателя или от него, обычно направляются
или получаются от Директора проекта, в то время, как
уведомления в адрес Поставщика или от него,
направляются
в
адрес
или
получаются
от
Представителя Поставщика, а в его отсутствие, от его
заместителя, если таковой существует. При отсутствии
Директора проекта или Представителя Поставщика
(или его заместителя), или, если их соответствующие
полномочия ограничены СУК Статьями 18.1 или 18.2.2
ОУК, либо по какой-либо другой причине, Покупатель
или Поставщик могут отправлять и получать
уведомления на свои резервные адреса. Адреса
Директора проекта и резервный адрес Покупателя
таковы, как указано в СУК, либо как установлены или
изменены в последствии. Адреса Представителя
Поставщика и резервный адрес Поставщика таковы, как
приведено в Приложении № 1 к Контрактному
соглашению, либо как установлены или изменены в
последствии.
5. Регулирующее
право
5.1
6. Урегулирование
споров
6.1
Контракт регулируется и интерпретируется в
соответствии с законодательством страны, указанной в
СУК.
Третейский суд
Раздел IV. Общие условия контракта
27
6.1.1 Если между Покупателем и Поставщиком
возникает какой-либо спор в связи с Контрактом
или по Контракту, включая без ущерба для общего
характера вышесказанного, спор по любому
вопросу, касающемуся самого существования,
юридической силы или окончания срока действия
Контракта, или работы Системы (будь-то в
процессе ее реализации или после доведения до
стадии Приемки в эксплуатацию, и будь-то до или
после окончания срока действия Контракта, отказа
от Контракта или его нарушения), стороны
должны стремиться разрешить такой спор путем
взаимных консультаций. Если стороны не могут
разрешить
такой
спор
путем
взаимных
консультаций в течение четырнадцати (14) дней
после того, как одна из сторон направила второй
стороне
письменное
уведомление
о
возникновении этого спора, то, если в
Приложении 2 к Контрактному соглашению
предусмотрен Третейский судья и указано его
имя, любая из сторон в течение других
четырнадцати (14) дней направляет спор этому
Третейскому судье в письменном виде, с копией
второй стороне. Если Третейский судья не
предусмотрен в Контрактном соглашении,
продолжительность упомянутого выше периода
взаимных
консультаций
составляет
не
четырнадцать (14), а двадцать восемь (28) дней, по
истечении которых любая из сторон может
направить уведомление о своем намерении
обратиться в арбитраж, как это предусмотрено в
Статье 6.2.1 ОУК.
6.1.2 Третейский судья должен (должна) вынести свое
решение в письменном виде, направив его обеим
сторонам в течение двадцати восьми (28) дней
после того, как спор был представлен на его (ее)
рассмотрение. Если Третейский судья сделал
(сделала) это и в течение следующих пятидесяти
шести (56) дней ни Покупатель, ни Поставщик не
направил уведомления о своем намерении
обратиться в арбитраж, вынесенное решение
является окончательным и обязательным и для
Покупателя, и для Поставщика. Любое решение,
которое стало окончательным и обязательным,
подлежит незамедлительному исполнению обеими
Раздел IV. Общие условия контракта
28
сторонами.
6.1.3 Третейский судья получает почасовую оплату по
ставке, указанной в Контрактном соглашении,
плюс компенсацию обоснованных расходов,
понесенных Третейским судьей при исполнении
своих обязанностей, причем эти издержки
оплачиваются Покупателем и Поставщиком в
равных долях.
6.1.4 В случае отставки или смерти Третейского судьи,
или в том случае, если Покупатель и Поставщик
согласятся с тем, что Третейский судья не
выполняет своих функций в соответствии с
условиями Контракта, Покупатель и Поставщик
совместно назначают нового Третейского судью.
Если стороны не смогут прийти к соглашению в
течение двадцати восьми (28) дней, новый
Третейский судья определяется Назначающим
органом, указанным в СУК, или, если в СУК нет
никаких указаний относительно Назначающего
органа, с этого момента и до тех пор, пока стороны
не достигнут договоренности в отношении
Третейского судьи или Назначающего органа,
Контракт исполняется так, как если бы Третейский
судья не был предусмотрен.
6.2
Арбитражное разбирательство
6.2.1 Если
(a)
Покупатель или Поставщик не удовлетворен
решением Третейского судьи и принимает
меры до того, как это решение станет
окончательным и обязательным согласно
Статье 6.1.2 ОУК, или
(b)
если Третейский судья не вынес никакого
решения в течение отведенного времени с
момента направления спора на рассмотрение
в соответствии со Статьей 6.1.2. ОУК и
Покупатель или Поставщик принимает меры
в течение последующих четырнадцати (14)
дней, или
(с)
в отсутствии указания Третейского судьи в
Контрактном
соглашении,
взаимные
консультации в соответствии со Статьей 6.1.1
ОУК не приводят к разрешению спора и
Раздел IV. Общие условия контракта
29
Покупатель или Поставщик принимает меры
в течение последующих четырнадцати (14)
дней,
то либо Покупатель, либо Поставщик может
направить второй стороне уведомление (с копией
для сведения Третейскому судье, если таковой
был вовлечен) о своем намерении обратиться для
урегулирования спора в арбитраж, как это
предусмотрено ниже, причем арбитражное
разбирательство этого спора не может быть
начато без направления такого уведомления.
6.2.2 Любой спор, в отношении которого было
направлено уведомление о намерении обратиться
в арбитраж (в соответствии со Статьей 6.2.1 ОУК),
подлежит окончательному урегулированию путем
арбитражного разбирательства. Арбитражное
разбирательство может быть начато как до, так и
после Установки Информационной системы.
6.2.3 Арбитражное разбирательство проводится в
соответствии с процессуальными нормами,
указанными в СУК.
6.3
Несмотря на любые ссылки на Третейского судью или
арбитражное разбирательство, которые имеются в
настоящей статье,
(a)
в отсутствие иной договоренности между
сторонами они продолжают выполнять свои
обязанности по Контракту;
(b)
Покупатель выплачивает Поставщику
причитающиеся ему суммы.
любые
B. ПРЕДМЕТ КОНТРАКТА
7. Состав Системы 7.1
Если в СУК или Технических требованиях нет иных
однозначных ограничений, в обязанности Поставщика
входит
предоставление
всех
Информационных
технологий, Материалов и прочих Товаров, а также
оказание всех Услуг, необходимых для проектирования,
разработки и реализации Системы (включая закупки,
обеспечение качества, сборку, соответствующую
подготовку площадки, Доставку, Подготовку к вводу в
эксплуатацию, Установку, Тестирование и Ввод в
Раздел IV. Общие условия контракта
30
эксплуатацию) в соответствии с планами, процедурами,
спецификациями, чертежами, нормами и всеми прочими
документами, перечисленными в Контракте, а также в
Согласованном и уточненном плане проекта.
8. Сроки начала
работ и
Приемки
Системы в
эксплуатацию
7.2
Если в Контракте нет конкретных положений,
исключающих указанное ниже, Поставщик выполняет
все работы и/или поставляет все позиции и Материалы,
которые специально не оговорены в Контракте, но
обоснованно вытекают из Контракта как необходимые
для обеспечения Приемки Системы в эксплуатацию, как
если бы такие работы и/или позиции и Материалы были
однозначно упомянуты в Контракте.
7.3
Обязанности Поставщика (если таковые имеются) в
части предоставления Товаров и Услуг, вытекающих из
Формы текущих расходов, приведенной в составе
конкурсного предложения Поставщика – например,
расходных материалов, запчастей и технических услуг
(техническое обслуживание, техническое содействие и
эксплуатационная поддержка) – перечислены в СУК,
включая соответствующие условия, характеристики и
сроки.
8.1
Поставщик должен приступить к работе над Системой в
течение периода времени, указанного в СУК, и без
ущерба для положений Статьи 28.2 ОУК в дальнейшем
Поставщик работает над Системой с соблюдением
сроков, указанных в Графике реализации, приведенном в
разделе “Технические требования”, с учетом любых
поправок,
внесенных
через
Согласованный
и
уточненный план проекта.
Поставщик должен довести Систему (или Подсистему
(Подсистемы), если Контракт предусматривает для этой
Подсистемы (Подсистем) отдельный срок) до стадии
Приемки в эксплуатацию за период времени, указанный
в СУК, и с соблюдением графика, указанного в Графике
реализации, приведенном в разделе “Технические
требования”, с учетом любых поправок, внесенных через
Согласованный и уточненный план проекта, или в
течение дополнительного времени, на которое
Поставщик имеет право в соответствии со Статьей 40
ОУК (Перенос Даты приемки в эксплуатацию на более
поздний срок).
8.2
Раздел IV. Общие условия контракта
9. Обязанности
Поставщика
31
9.1
Поставщик осуществляет любую деятельность с
должной тщательностью и прилежанием, в соответствии
с Контрактом и настолько квалифицированно и
аккуратно, насколько это можно ожидать от
компетентного
Поставщика
информационных
технологий, информационных систем, а также услуг,
связанных с поддержкой, техническим обслуживанием,
обучением персонала, и прочих соответствующих услуг,
или с применением наилучшей в этой области практики.
В частности, Поставщик должен предоставлять и
нанимать только тех технических сотрудников, у
которых есть соответствующая профессиональная
квалификация и опыт, и управляющий персонал,
способный осуществлять надлежащий контроль за
выполнением работ.
9.2
Поставщик подтверждает, что заключил настоящий
Контракт по итогам тщательной проверки информации,
касающейся
данной
Системы,
которая
была
предоставлена Покупателем, и с учетом сведений,
которые Поставщик смог получить в результате
визуального осмотра площадки (если у него к ней был
доступ), а также других данных о Системе, к которым
Поставщик мог иметь свободный доступ за двадцать
восемь (28) дней до подачи конкурсного предложения.
Поставщик признает, что невозможность ознакомления
со всеми этими сведениями и данными не освобождает
его от ответственности за правильную оценку всей
сложности или стоимости успешного выполнения
Контракта.
9.3
Поставщик несет ответственность за своевременное
предоставление всех ресурсов и информации и
своевременное принятие зависящих от него решений,
которые необходимы для составления Согласованного
обеими сторонами и уточненного плана проекта
(согласно Статье 19.2 ОУК) в сроки, указанные в
Графике
реализации,
приведенном
в
разделе
“Технические требования”. Непредоставление таких
ресурсов и информации и непринятие таких решений
может стать основанием для расторжения Контракта в
соответствии со Статьей 41.2 ОУК.
9.4
Поставщик должен получить на свое имя все
разрешения, санкции и/или лицензии от любых местных,
региональных или национальных органов власти или
подразделений государственной службы в Стране
Раздел IV. Общие условия контракта
32
Покупателя, которые необходимы для выполнения
Контракта,
включая,
без
ограничения
нижеперечисленным, визы для сотрудников Поставщика
и Субподрядчика и разрешения на ввоз всего
подлежащего
ввозу
Оборудования
Поставщика.
Поставщик должен получить все прочие разрешения,
санкции и/или лицензии, которые не являются
обязанностью Покупателя в соответствии со Статьей
10.4 ОУК и необходимы для выполнения Контракта.
9.5
Поставщик должен соблюдать все законы, действующие
в Стране Покупателя. К числу таких законов относятся
все национальные, региональные, муниципальные и
иные законы, которые распространяются на выполнение
Контракта и являются обязательными для Поставщика.
Без ущерба для положений Статьи 10.1 ОУК Поставщик
должен гарантировать Покупателю возмещение убытков
и оградить его от любого и всех обязательств, видов
ущерба, исков, штрафов, штрафных санкций и расходов,
возникающих в связи или в результате нарушения этих
законов Поставщиком или его сотрудниками. Поставщик
не должен возмещать Покупателю убытки в той степени,
в какой эти обязательства, ущерб, иски, штрафы,
штрафные санкции и расходы возникли по вине или в
связи с оплошностью Покупателя.
9.6
В отношениях со своими сотрудниками и сотрудниками
своих Субподрядчиков, которые в настоящее время
выполняют Контракт или связаны с ним, Поставщик
должен всегда соблюдать все общепризнанные
фестивали, официальные праздники, религиозные и
иные обычаи, а также все местные законы и
нормативные акты, касающиеся найма работников.
Страной происхождения (как это определено в Статье
3.12 ОУК) любых Информационных технологий или
иных Товаров и Услуг, которые войдут в состав или
потребуются для Системы, а также прочих поставок
должна быть Правомочная страна в соответствии с
определением этого термина в Статье 1.1 (e) (iv) ОУК.
Поставщик разрешит Банку и/или лицам, назначенным
Банком, проинспектировать офисы Поставщика и/или
его счета и учетные документы, относящиеся к его
работе по Контракту, и по требованию Банка
предоставит их для проверки аудиторам, которые
назначены Банком. Поставщик должен внимательно
отнестись к Статье 41.2.1(с), которая, помимо прочего,
предусматривает, что действия, направленные на
9.7
9.8
Раздел IV. Общие условия контракта
33
физическое затруднение проведения Банковской
инспекции или прав аудитора, указанных в Статье 9.8Ю
представляют
собой
недопустимое
действие,
приводящее к расторжению контракта (а также к
признанию неправомочности по Руководству о закупках.
9.9
10. Обязанности
Покупателя
Прочие обязанности Поставщика
имеются) перечислены в СУК.
(если
таковые
10.1 За исключением случаев, четко оговоренных в
Контракте, Покупатель обеспечивает точность всех
сведений и/или данных, которые он должен
предоставить Поставщику.
10.2 Покупатель несет ответственность за своевременное
предоставление всех ресурсов и информации и
своевременное принятие зависящих от него решений,
которые необходимы для составления Согласованного и
уточненного плана проекта (согласно Статье 19.2 ОУК) в
сроки, указанные в Графике реализации, приведенном в
разделе “Технические требования”. Непредоставление
таких ресурсов и информации и непринятие таких
решений может стать основанием для расторжения
Контракта в соответствии со Статьей 41.3.1(b) ОУК.
10.3 Покупатель несет ответственность за приобретение
площадки, обеспечение юридического и физического
владения площадкой и доступа к ней, а также за
обеспечение владения и доступа ко всем прочим
территориям,
обоснованно
необходимым
для
надлежащего выполнения Контракта.
10.4 По просьбе Поставщика, Покупатель должен сделать все
возможное, чтобы помочь Поставщику своевременно и
оперативно получить от любых местных, региональных
или национальных органов власти или подразделений
государственной службы все необходимые для
выполнения Контракта разрешения, санкции и/или
лицензии, которые Поставщик или Субподрядчики, или
сотрудники Поставщика или Субподрядчиков (в
зависимости от обстоятельств) обязаны получить в
соответствии с требованиями этих органов власти или
подразделений.
10.5 В тех случаях, когда в обязанности Поставщика входят
точное определение и приобретение или модернизация
услуг
в
области
телекоммуникаций
и/или
энергоснабжения, как это указано в Технических
требованиях, СУК, Согласованном и уточненном плане
проекта или других частях Контракта, Покупатель
Раздел IV. Общие условия контракта
34
должен сделать все возможное, чтобы помочь
Поставщику своевременно и оперативно получить такие
услуги.
10.6 Покупатель несет ответственность за своевременное
предоставление всех ресурсов, доступа и информации,
которые необходимы для Установки Системы и ее
Приемки в эксплуатацию (включая, без ограничения
нижеперечисленным, все необходимые услуги в области
телекоммуникаций и энергоснабжения) и указаны в
Согласованном и уточненном плане проекта, за
исключением случаев, когда их предоставление четко
определено в Контракте как обязанность Поставщика. В
случае задержки со стороны Покупателя Дата приемки в
эксплуатацию может быть соответственно перенесена на
более поздний срок по усмотрению Поставщика.
10.7 В отсутствие иных указаний в Контракте или иных
договоренностей между Покупателем и Поставщиком,
Покупатель
должен
предоставить
достаточное
количество операторов и технических сотрудников,
имеющих
необходимую
квалификацию,
чтобы
Поставщик мог надлежащим образом осуществить
Доставку, Подготовку к вводу в эксплуатацию,
Установку, Ввод в эксплуатацию и Приемку в
эксплуатацию к наступлению или до наступления
сроков, указанных в Графике реализации, приведенном в
разделе “Технические требования”, или в Согласованном
и уточненном плане проекта.
10.8 Покупатель выделяет необходимых сотрудников для
прохождения
курса
обучения,
который
будет
организован
Поставщиком,
и
принимает
все
необходимые организационно-технические меры для
проведения такого обучения, которые перечислены в
Технических требованиях, СУК, Согласованном и
уточненном плане проекта или других частях Контракта.
10.9 Покупатель берет на себя основную ответственность за
проведение Приемочных испытаний Системы в
соответствии со Статьей 27.2 ОУК и отвечает за
дальнейшую работу Системы после Приемки в
эксплуатацию. Однако это никак не ограничивает другие
обязанности
Поставщика
после
Приемки
в
эксплуатацию, которые оговорены в Контракте.
10.10 Покупатель несет ответственность за создание и
безопасное хранение резервных копий своих данных и
Программных продуктов, своевременно и регулярно
создаваемых
в
соответствии
с
приемлемыми
принципами управления данными, за исключением
Раздел IV. Общие условия контракта
35
случаев, когда другие положения Контракта однозначно
возлагают эту ответственность на Поставщика.
10.11 Все издержки и расходы, связанные с выполнением
обязанностей в рамках настоящей Статьи 10 ОУК,
оплачиваются Покупателем, за исключением издержек и
расходов, понесенных Поставщиком в связи с
проведением Приемочных испытаний согласно Статье
27.2 ОУК.
10.12 Прочие обязанности Покупателя (если таковые
имеются) перечислены в СУК.
C. ПЛАТЕЖ
11. Цена контракта
11.1 Цена контракта указана в Статье 2 Контрактного
соглашения (Цена контракта и условия платежа).
11.2 Цена контракта является твердой суммой, не
подлежащей никаким изменениям, за исключением:
(a) случаев Изменения Системы в соответствии со
Статьей 39 ОУК или другими статьями Контракта;
(b) случаев
корректировки
в
соответствии
с
корректировочной
формулой
(если
таковая
имеется), приведенной в СУК.
11.3 Считается, что Поставщик убежден в правильности и
достаточности Цены контракта, которая охватывает (за
исключением иных положений, оговоренных в
Контракте) все обязанности Поставщика в рамках
Контракта.
12. Условия
платежа
12.1 После выполнения прочих обязанностей, оговоренных в
Контракте, Поставщик направляет Покупателю запрос о
платеже в письменном виде, прилагая к нему счетфактуру с описанием (в зависимости от обстоятельств)
Системы или Подсистемы (Подсистем), которая была
Доставлена, Подготовлена к вводу в эксплуатацию и
Установлена и прошла Приемочные испытания, а также
документы, представленные в соответствии со Статьей
22.5 ОУК.
Цена контракта выплачивается так, как указано в СУК.
12.2 Ни один платеж, произведенный Покупателем на
основании изложенного в настоящем документе, не
считается приемкой Системы или Подсистемы
(Подсистем) Покупателем.
Раздел IV. Общие условия контракта
36
12.3 Покупатель производит платежи без задержки, но ни в
коем случае не позднее, чем через сорок пять (45) дней
после представления Поставщиком действительного
счета-фактуры. В случае, если Покупатель не
производит платеж к наступлению соответствующего
срока или в течение периода времени, установленного в
Контракте, Покупатель выплачивает Поставщику
проценты по сумме просроченного платежа за весь
период задержки по ставке (ставкам), указанным в
СУК, пока не будет полностью произведен весь платеж
– будь-то до или после вынесения судебного или
арбитражного решения.
12.4 Все платежи производятся в валюте (валютах),
указанных в Контрактном соглашении, в соответствии со
Статьей 11 ОУК. Что касается поставки местных
Товаров и Услуг, платежи производятся в валюте
Страны Покупателя, если в СУК нет иных указаний.
12.5 Если в СУК нет иных указаний, выплата Поставщику
инвалютной части Цены контракта за Товары,
поставляемые из-за рубежа, осуществляется через
безотзывный аккредитив, открытый полномочным
банком в Стране Поставщика, и производится после
представления необходимых документов. Стороны
соглашаются с тем, что такой аккредитив подпадает под
Статью 10 последней редакции Унифицированных
правил документарных аккредитивов, опубликованной
Международной торговой палатой (Париж).
13. Обеспечение
13.1 Предоставление залогового обеспечения
Поставщик предоставляет Покупателю указанное ниже
залоговое
обеспечение,
сроки,
сумма,
способ
предоставления и форма которого оговорены ниже.
13.2 Залоговое обеспечение авансового платежа
13.2.1 Как указано в СУК, Поставщик должен
предоставить залоговое обеспечение на ту же
сумму и в той же валюте, что и авансовый платеж,
и это залоговое обеспечение остается в силе
вплоть до Приемки Системы в эксплуатацию.
13.2.2 Залоговое обеспечение оформляется так, как
указано в Документации для торгов, или иным
образом, приемлемым для Покупателя. Сумма
залогового
обеспечения
периодически
Раздел IV. Общие условия контракта
37
уменьшается
пропорционально
стоимости
Системы,
выполненной
Поставщиком
и
оплаченной ему, и автоматически сокращается до
нуля и теряет силу, когда Покупатель полностью
выплатит весь авансовый платеж. Порядок
уменьшения и последующего аннулирования
залогового обеспечения указан в СУК. После
того, как залоговое обеспечение утратит силу, оно
незамедлительно возвращается Поставщику.
13.3 Залоговое обеспечение выполнения Контракта
13.3.1 В течение двадцати восьми (28) дней после
направления уведомления о присуждении
Контракта Поставщик должен предоставить
залоговое обеспечение надлежащего выполнения
Контракта, сумма и валюта которого указаны в
СУК.
13.3.2 Это залоговое обеспечение должно быть
представлено в форме банковской гарантии,
оформленная так, как указано разделе “Образцы
форм” Документации для торгов, или в другой
форме, приемлемой для Покупателя.
13.3.3 Это залоговое обеспечение автоматически
сокращается до нуля и теряет силу, как только
Поставщик выполнит все свои обязанности в
рамках Контракта, включая, без ограничения
нижеперечисленным,
все
обязанности
Гарантийного периода и любого дополнительного
Гарантийного периода. Залоговое обеспечение
возвращается Поставщику не позднее, чем через
двадцать восемь (28) дней после того, как оно
утратит силу.
13.3.4 После Приемки в эксплуатацию всей Системы, в
день осуществления такой Приемки, сумма
обеспечения будет уменьшена до значения,
указанного в СУК, с тем, чтобы уменьшенное
обеспечение покрывало только остающиеся
гарантийные обязательства Поставщика.
14. Налоги и
пошлины
14.1 При поставке Товаров и Услуг из стран, не являющихся
Страной Покупателя, Поставщик несет всю полноту
ответственности за уплату любых налогов, гербовых и
лицензионных сборов и прочих начислений, взимаемых
за пределами Страны Покупателя. Покупатель несет
Раздел IV. Общие условия контракта
38
ответственность за уплату любых пошлин (например,
импортных или таможенных), налогов и сборов,
подлежащих уплате на территории страны Покупателя за
поставку Товаров и Услуг из-за рубежа, за исключением
ситуаций, когда такие пошлины или налоги включены в
Цену Контракта согласно Статье 2 Контрактного
соглашения, а также в Таблицу цен, к которой они
относятся. В этом случае уплата таких пошлин и налогов
является обязанностью Поставщика.
14.2 При поставке местных Товаров и Услуг Поставщик
несет всю полноту ответственности за уплату любых
налогов, пошлин, лицензионных сборов и т.д.,
начисленных до того, как контрактные Товары и Услуги
были
доставлены
Покупателю.
Единственным
исключением являются такие налоги или пошлины, как
налог на добавленную стоимость или налог с продаж,
или гербовый сбор, которые распространятся на счетафактуры или могут быть четко выделены из счетовфактур, при условии, что они действуют в Стране
Покупателя и только в том случае, если эти налоги,
сборы и/или пошлины исключены также из Цены
контракта согласно Статье 2 Контрактного соглашения и
Таблице цен, к которой они относятся.
14.3 Если
в
Стране
Покупателя
на
Поставщика
распространяются какие-либо налоговые льготы, скидки
или привилегии, Покупатель должен сделать все, что в
его силах, чтобы Поставщик в максимальной степени
воспользовался этой возможностью экономии налогов.
14.4 Для целей Контракта стороны соглашаются с тем, что
Цена контракта, указанная в Статье 2 Контрактного
соглашения (Цена контракта и условия платежа)
учитывает налоги, пошлины, сборы и начисления
(именуемые также “Налог” в настоящей Статье 14.4
ОУК), действующие в Стране Покупателя за двадцать
восемь (28) дней до срока подачи конкурсных
предложений. Если в процессе выполнения Контракта
произойдет увеличение или уменьшение каких-либо
ставок Налога, введение нового Налога, отмена
существующего Налога или изменение интерпретации
или применения какого-либо Налога, который взимался
или будет взиматься с Поставщика, его Субподрядчиков
или их работников в связи с выполнением Контракта,
Цена контракта будет соответствующим образом
скорректирована в целях надлежащего учета такого
изменения за счет увеличения или уменьшения Цены
контракта (в зависимости от обстоятельств).
Раздел IV. Общие условия контракта
39
D. ИНТЕЛЛЕКТУАЛЬНАЯ СОБСТВЕННОСТЬ
15. Авторские
права
15.1 Права интеллектуальной собственности на все
Стандартные программные продукты и Стандартные
материалы остаются у владельца таких прав.
15.2 Покупатель соглашается ограничить использование,
копирование
или
дублирование
Стандартных
программных продуктов и Стандартных материалов в
соответствии со Статьей 16 ОУК, за исключением того,
что Покупатель может сделать дополнительные копии
Стандартных материалов для использования в рамках
проекта, частью которого является Система, если
Поставщик не предоставит копии в течение тридцати
(30) дней после получения запроса на такие
Стандартные материалы.
15.3 Контрактные права Покупателя на использование
Стандартных программных продуктов
или их
компонентов не подлежат переуступке, лицензированию
или иной добровольной передаче, кроме как на
основании
соответствующего
лицензионного
соглашения или иных положений, которые могут быть
оговорены в СУК.
15.4 Насколько это применимо, права и обязанности
Покупателя
и
Поставщика
в
отношении
Кастомизированных программных продуктов или их
компонентов, включая все лицензионные соглашения, а
также в отношении Кастомизированных материалов или
их компонентов определены в СУК. С учетом
положений
СУК
Права
интеллектуальной
собственности на все Кастомизированные программные
продукты
и
Кастомизированные
материалы,
определенные в Приложениях 4 и 5 к Контрактному
соглашению (если таковые имеются) по состоянию на
день заключения этого Контракта или по состоянию на
день возникновения таких прав (если он наступает
позднее дня заключения Контракта), принадлежат
Покупателю. Поставщик принимает и оформляет или
обеспечивает принятие и оформление всех актов,
документов и мер, которые Покупатель считает
необходимыми или желательными для окончательного
закрепления права, титула и доли участия Покупателя в
этих правах и на эти права. Что касается таких
Кастомизированных
программных
продуктов
и
Раздел IV. Общие условия контракта
40
Кастомизированных материалов, Поставщик принимает
меры к тому, чтобы владелец морального права на
любой такой продукт или материал не предъявлял своего
права, и в случае получения соответствующей просьбы
от Покупателя и если это допускается применимым
законодательством, Поставщик должен принять меры к
тому, чтобы владелец такого морального права отказался
от него.
16. Лицензии на
Программные
продукты
15.5 В соответствии с положениями СУК стороны должны
заключить
“эскроу”-соглашения
(если
таковые
необходимы) в отношении Исходного текста некоторых
или всех Программных продуктов, как это указано в
СУК.
16.1 За исключением случаев, когда Права интеллектуальной
собственности на Программные продукты принадлежат
Покупателю, Поставщик настоящим дает Покупателю
лицензию на доступ к Программным продуктам и
пользование ими, включая все изобретения, проекты и
торговые
знаки,
инкорпорированные
в
этих
Программных продуктах.
Такая лицензия на доступ к Программным продуктам и
пользование ими:
(a)
должна:
(i)
носить неэксклюзивный характер;
(ii)
быть полностью оплаченной и безотзывной
(за исключением того, что ее действие
заканчивается
в
случае
расторжения
Контракта на основании Статей 41.1 или 41.3
ОУК);
(iii) действовать на всей территории Страны
Покупателя (или иной территории, указанной
в СУК); и
(iv) подпадать под дополнительные ограничения
(если таковые имеются), перечисленные в
СУК.
(b)
должна предусматривать
продуктов возможность:
(i)
для
Программных
использования
или
копирования
для
использования на компьютере (компьютерах),
для которых они были приобретены (если это
определено в Технических требованиях и/или
Раздел IV. Общие условия контракта
41
конкурсном предложении Поставщика), и на
резервном компьютере (компьютерах) той же
или аналогичной мощности, если главный
компьютер (главные компьютеры) находится
(находятся) в нерабочем состоянии, а также в
течение разумного переходного периода,
когда работа переносится с главного
компьютера на резервный и наоборот;
(ii)
как это указано в СУК, использования или
копирования для использования или переноса
на замещающий компьютер (компьютеры)
(причем в течение разумного переходного
периода использование на первоначальном и
замещающем компьютере (компьютерах)
может происходить одновременно) при
условии, что, если в Технических требованиях
и/или конкурсном предложении Поставщика
оговорен
класс
компьютера,
которым
ограничивается лицензия и если нет иных
письменных договоренностей с Поставщиком,
замещающий
компьютер
(компьютеры)
должен (должны) относиться к тому же
классу;
(iii) доступа к ним с других компьютеров,
соединенных с главным и/или резервным
компьютером (компьютерами) в рамках
локальной или территориальной сети, или
аналогичной системы, если характер Системы
допускает такой доступ, а также их
использования
или
копирования
для
использования на таких других компьютерах,
насколько это нужно для получения
указанного доступа;
(iv) воспроизведения
в
целях
обеспечения
безопасного хранения или создания резервных
копий;
(v)
кастомизации, адаптации или комбинирования
с другим программным обеспечением для
использования Покупателем, при условии, что
производное
программное
обеспечение,
содержащее какую-либо существенную часть
поставленных защищенных Программных
продуктов, подпадает под ограничения,
Раздел IV. Общие условия контракта
42
изложенные в настоящем Контракте;
(vi) как это указано в СУК, раскрытия
информации о Программных продуктах
поставщикам вспомогательных услуг и их
субподрядчикам и их воспроизведения для
использования такими поставщиками и их
субподрядчиками (причем Покупатель может
заключать с такими лицами сублицензионные
соглашения на использование и копирование
Программных продуктов) в той степени, в
какой это необходимо для выполнения
договоров о предоставлении вспомогательных
услуг, при условии соблюдения ограничений,
изложенных в настоящем Контракте; и
(vii) раскрытия информации о Программных
продуктах Покупателю и прочим лицам,
перечисленным
в
СУК,
и
их
воспроизведения
для
использования
Покупателем и такими лицами (причем
Покупатель может заключать с этими лицами
сублицензионные
соглашения
на
использование и копирование Программных
продуктов),
при
условии
соблюдения
ограничений, изложенных в настоящем
Контракте.
17.
Конфиденци
альная
информация
16.2 Поставщик может проводить аудит Стандартных
программных продуктов на условиях, изложенных в
СУК, в целях проверки их соответствия указанным
выше лицензионным соглашениям.
17.1 За исключением иных условий, оговоренных в СУК,
“Сторона, получающая информацию” (либо Покупатель,
либо
Поставщик)
должны
соблюдать
конфиденциальность и без письменного согласия второй
стороны
настоящего
Контракта
(“Сторона,
раскрывающая информацию”) не должны раскрывать
третьим лицам какие-либо документы, данные или иную
информацию
конфиденциального
характера
(“Конфиденциальная
информация”,
связанную
с
Контрактом и напрямую или косвенно полученную
Стороной, раскрывающей информацию, до, во время или
по завершении исполнения Контракта.
17.2 Для целей Статьи 17.1 ОУК Поставщик является
Стороной,
получающей
конфиденциальную
Раздел IV. Общие условия контракта
43
информацию, генерируемую самим Поставщиком в
процессе выполнения его обязанностей в рамках
Контракта и касаются дел, финансов, поставщиков,
сотрудников или иных контактов Покупателя или
использования Системы Покупателем,
17.3 Несмотря на положения Статей 17.1 и 17.2 ОУК::
(a)
Поставщик может раскрыть своему Субподрядчику
Конфиденциальную информацию Покупателя в том
объеме, в каком это необходимо Субподрядчику
для выполнения работы по Контракту; и
(b)
Покупатель может раскрыть Конфиденциальную
информацию Поставщика: (i) своим поставщикам
вспомогательных услуг и их субподрядчикам в том
объеме, в каком это им необходимо для
выполнения работы по договорам о предоставлении
вспомогательных
услуг;
и
(ii)
своим
аффилированным компаниям и филиалам,
и в этом случае Сторона, получающая информацию,
должна принять меры к тому, чтобы лицо, которому она
передает Конфиденциальную информацию Стороны,
раскрывающей информацию, было осведомлено об
обязанностях Стороны, получающей информацию,
которые изложены в настоящей Статье 17 ОУК, и
соблюдало их, как если бы это лицо было стороной
Контракта вместо Стороны, получающей информацию.
17.4 Без предварительного письменно согласия Поставщика
Покупатель не должен использовать полученную от
Поставщика Конфиденциальную информацию для
каких-либо
иных
целей,
кроме
эксплуатации,
технического обслуживания и дальнейшего развития
Системы.
Аналогично,
без
предварительного
письменного согласия Покупателя Поставщик не должен
использовать
полученную
от
Покупателя
Конфиденциальную информацию для каких-либо иных
целей, кроме тех, что необходимы для выполнения
Контракта.
17.5 Тем не менее, обязанности стороны в рамках Статей 17.1
– 17.4 ОУК не распространяются на информацию,
которая:
(a)
сейчас или впоследствии будет предана огласке не
по вине Стороны, получающей информацию;
Раздел IV. Общие условия контракта
44
(b)
как это доказано, на момент раскрытия уже
находилась в распоряжении Стороны, получающей
информацию, и до этого не была получена – прямо
или косвенно – от Стороны, раскрывающей
информацию;
(c)
становится
известна
Стороне,
получающей
информацию, иным законным образом от третьего
лица, не связанного обязательством соблюдения
конфиденциальности.
17.6 Изложенные выше положения настоящей Статьи 17
ОУК никак не влияют на обязательства соблюдения
конфиденциальности, которые любая из сторон
настоящего Контракта взяла на себя в отношении
Системы или любой ее части до дня заключения этого
Контракта.
17.7 Положения настоящей Статьи 17 ОУК остаются в силе
после окончания срока действия (по любой причине)
этого Контракта в течение трех (3) лет или более
длительного периода времени, который может быть
указан в СУК.
E. ПОСТАВКА, УСТАНОВКА, ТЕСТИРОВАНИЕ, ВВОД В
ЭКСПЛУАТАЦИЮ И ПРИЕМКА СИСТЕМЫ
18.
Представители 18.1 Директор проекта
Если фамилия Директора проекта не указана в
Контракте, то в течение четырнадцати (14) дней после
Даты вступления в силу Покупатель должен назначить
Директора проекта и сообщить его фамилию
Поставщику в письменном виде. Покупатель имеет
право периодически назначать Директором проекта
других лиц вместо того, кто был назначен раньше, и
должен незамедлительно сообщать их фамилии
Поставщику. Сроки или порядок назначения таких лиц
не должны мешать ходу работ над Системой.
Назначение считается вступившим в силу только после
того, как Поставщик получит соответствующее
уведомление. С учетом расширения и/или ограничения
прав, указанных в СУК (если таковые имеются),
Директор проекта будет уполномочен представлять
Покупателя в повседневных делах, касающихся
Раздел IV. Общие условия контракта
45
Системы, или связанных с Контрактом и обычно будет
являться лицом, которое будет давать и получать
уведомления от имени Покупателя согласно Статье 4
ОУК.
18.2 Представитель Поставщика
18.2.1 Если Представитель Поставщика не поименован в
Контракте, то в течение четырнадцати (14) дней
после Даты вступления в силу Покупатель должен
назначить Представителя Поставщика и направить
Покупателю письменный запрос об утверждении
назначенного лица. К запросу должны прилагаться
подробная биография кандидата, а также описание
всех прочих функций, касающихся и не
касающихся Системы, которые кандидат сохранит
за собой в процессе выполнения обязанностей
Представителя Поставщика. Если Покупатель не
возражает против такого назначения в течение
четырнадцати (14) дней, кандидатура этого
Представителя
Поставщика
считается
утвержденной. Если Покупатель возражает против
такого назначения в течение четырнадцати (14)
дней с указанием причин своего возражения, то
Поставщик должен назначить другое лицо в
течение четырнадцати (14) дней после получения
такого возражения в соответствии с настоящей
Статьей 18.2.1 ОУК.
18.2.2 С учетом расширения и/или ограничения прав,
указанных в СУК (если таковые имеются),
Представитель Поставщика будет уполномочен
представлять Поставщика в повседневных делах,
касающихся
Системы,
или
связанных
с
Контрактом, и обычно будет лицом, которое будет
давать и получать уведомления от имени
Поставщика согласно Статье 4 ОУК.
18.2.3 Поставщик не имеет права отменять назначение
Представителя Поставщика без предварительного
письменного согласия Покупателя, который не
должен безосновательно отказывать в таком
согласии. Если Покупатель соглашается с такой
отменой, Поставщик, действуя в соответствии с
процедурами, изложенными в Статье 18.2.1 ОУК,
должен назначить Представителем Поставщика
другое лицо, имеющее аналогичную или более
Раздел IV. Общие условия контракта
46
высокую квалификацию,.
18.2.4 Представитель и персонал Поставщика обязаны
работать в тесном сотрудничестве с Директором
проекта и персоналом Покупателя, действовать в
пределах своей компетенции и выполнять все
указания Покупателя, отвечающие условиям
Контракта. Представитель Поставщика несет
ответственность за управление деятельностью
персонала Поставщика, а также всех работников,
привлеченных по договорам субподряда.
18.2.5 С согласия Покупателя (который не должен
безосновательно отказывать в таком согласии)
Представитель Поставщика имеет право в любое
время делегировать любое из своих полномочий,
функций или прав любому лицу. Полномочия,
функции или права, делегированные таким
образом, могут быть отозваны в любое время. В
случае такого делегирования или отзыва
полномочий, функций или прав Представитель
Поставщика должен предварительно выпустить
соответствующее уведомление с указанием
делегируемых или отзываемых полномочий,
функций или прав. Делегирование или отзыв
считается вступившим в силу только после того,
как такое уведомление будет доставлено.
18.2.6 Любой акт или действие, совершенные любым
лицом, которому были делегированы полномочия,
функции или права в соответствии со Статьей
18.2.5 ОУК, считаются актом или действием,
совершенными Представителем Поставщика.
18.3 Возражение и отстранение от работы
18.3.1
Направив
соответствующее
уведомление
Поставщику, Покупатель имеет право заявить
возражение против любого представителя или
лица,
привлеченного
Поставщиком
для
выполнения Контракта, если у Покупателя есть
основания считать, что он (она) вел (вела) себя не
подобающим образом, является некомпетентным
(некомпетентной) или небрежно выполняет свои
обязанности. В подтверждение своего мнения
Покупатель должен представить доказательства,
после чего Поставщик должен отстранить это лицо
Раздел IV. Общие условия контракта
47
от работы над Системой.
18.3.2 Если какой-либо представитель или лицо,
привлеченное Поставщиком, отстраняется от
работы на основании Статьи 18.3.1 ОУК,
Поставщик (в случае необходимости) должен
незамедлительно назначить ему замену.
19. План проекта
19.1 В тесном взаимодействии с Покупателем и на основании
Предварительного плана проекта, включенного в состав
его
конкурсного
предложения,
Поставщик
разрабатывает План проекта, охватывающий те виды
деятельности, которые предусмотрены в Контракте.
Содержание Плана проекта должно соответствовать
положениям, приведенным в СУК и/или в Технических
требованиях.
19.2 Поставщик официально представляет Покупателю План
проекта так, как это указано в СУК.
19.3 В случае необходимости, изменения, согласованные в
ходе окончательной доработки Согласованного и
уточненного плана проекта, которые оказывают влияние
на График реализации, включаются в Контракт в виде
поправок в соответствии со Статьями 39 и 40 ОУК.
19.4 Поставщик обязуется обеспечить поставку, установку,
тестирование Системы и ее ввод в эксплуатацию в
соответствии с Согласованным и уточненным планом
проекта и Контрактом.
19.5 Поставщик готовит и представляет Покупателю отчеты о
ходе работ и прочие перечисленные в СУК отчеты,
форма и сроки представления которых определены в
Технических требованиях.
20. Заключение
договоров
субподряда
20.1 В Приложении 3 к Контрактному соглашению (Перечень
утвержденных
Субподрядчиков)
перечислены
важнейшие поставляемые позиции или услуги, и для
каждой позиции приведен перечень Субподрядчиков,
которых Покупатель считает приемлемыми. Если
напротив позиции нет никаких указаний относительно
Субподрядчиков, Поставщик должен составить список
Субподрядчиков, которые, по его мнению, обладают
необходимой квалификацией и которых он хочет
включить в перечень Субподрядчиков по данной
позиции. Поставщик может периодически вносить
Раздел IV. Общие условия контракта
48
предложения
о включении
в
этот
перечень
дополнительных кандидатур или исключении из него
существующих Субподрядчиков. Для того, чтобы не
задерживать ход работы над Системой, Поставщик
заблаговременно
представляет
на
утверждение
Покупателя такой перечень или любые поправки к нему.
Покупатель не должен безосновательно отказывать в
утверждении
Субподрядчиков.
Утверждение
Покупателем
какого-либо
Субподрядчика
(Субподрядчиков) не освобождает Поставщика от его
обязательств, обязанностей или видов ответственности в
рамках Контракта.
20.2 Поставщик, по своему усмотрению, может выбирать и
нанимать Субподрядчиков по указанным выше
важнейшим
позициям,
оперируя
перечнем
Субподрядчиков, составленным в соответствии со
Статьей 20.1 ОУК. Если Поставщик хочет нанять
Субподрядчика, не вошедшего в этот перечень, или
заключить договор субподряда на позицию, не
относящуюся
к
этому перечню,
он
должен
предварительно получить согласие Покупателя в
соответствии со Статьей 20.3 ОУК.
20.3 Что касается позиций, по которым в Приложении 3 к
Контрактному
соглашению
нет
предварительно
утвержденных перечней Субподрядчиков, то Поставщик
может нанимать Субподрядчиков по своему выбору при
условии, что: (i) Поставщик направит Покупателю
письменное уведомление о выбранном Субподрядчике,
как минимум, за двадцать восемь (28) дней до
предполагаемой
даты
мобилизации
этого
Субподрядчика, и (ii) к концу этого периода Покупатель
либо дает свое согласие, либо не присылает никакого
ответа. Поставщик не может нанять Субподрядчика,
против которого Покупатель возразил в письменном
виде до истечения срока действия уведомления.
Отсутствие письменного возражения Покупателя в
течение указанного периода времени является
официальным согласием с кандидатурой предложенного
Субподрядчика.
За
исключением
того,
что
Субподрядчиков, не перечисленных в Контрактном
соглашении,
можно
считать
утвержденными
Покупателем на основании настоящей Статьи, ни одно
ее положение не ограничивает прав и обязанностей
Покупателя или Поставщика, установленных в Статьях
20.1 и 20.2 ОУК, в СУК или Приложении 3 к
Раздел IV. Общие условия контракта
49
Контрактному соглашению.
21. Проектноконструкторска
я документация
21.1 Технические условия и чертежи
21.1.1
Поставщик
выполняет
базовые
и
детализированные проектно-конструкторские и
физические работы, необходимые для успешной
установки Системы в соответствии с условиями
Контракта или, если эти условия не оговорены в
Контракте, в соответствии с добротной практикой,
принятой в данной отрасли.
Поставщик несет ответственность за любые
расхождения,
ошибки
или
упущения
в
спецификациях, чертежах и прочих технических
документах, которые он подготовил, независимо
от того, были ли эти спецификации, чертежи и
прочие документы одобрены Директором проекта,
при условии, что причиной таких расхождений,
ошибок или упущений не является неточная
письменная
информация,
предоставленная
Поставщику самим Покупателем или от его имени.
21.1.2 Поставщик
имеет
право
отказаться
от
ответственности за любые технические проекты,
данные, чертежи, спецификации или иные
документы, или любые поправки к таким
техническим проектам, чертежам, спецификациям
или
иным
документам,
которые
были
предоставлены или разработаны Покупателем или
от его имени, направив Директору проекта
уведомление об отказе от ответственности.
21.2 Нормы и стандарты
В отсутствие иных указаний в СУК любые ссылки в
Контракте на нормы и стандарты, которые следует
соблюдать
при
выполнении
Контракта,
предусматривают применение той редакции или
пересмотренной версии таких норм и стандартов,
которая была действительна за двадцать восемь (28) до
истечения срока подачи конкурсных предложений.
Любое изменение таких норм и стандартов в период
выполнения Контракта приобретает силу после
утверждения Покупателем и вносится в соответствии со
Статьей 39.3 ОУК.
21.3 Утверждение/рассмотрение
технических
документов
Раздел IV. Общие условия контракта
50
Директором проекта
21.3.1 Поставщик
готовит
и
представляет
на
утверждение или рассмотрение Директора проекта
документы, указанные в СУК.
Любая
часть
Системы,
на
которую
распространяются или к которой относятся
документы,
подлежащие
утверждению
Директором проекта, выполняется только после
того, как Директор проекта утвердит эти
документы.
Статьи с 21.3.2 по 21.3.7 ОУК распространяются
на те документы, которые утверждаются
Директором проекта, но не распространяются на
документы, которые направляются Директору
проекта только для рассмотрения.
21.3.2 В течение четырнадцати (14) дней после того, как
Директор проекта получит любой документ,
требующий утверждения Директором проекта в
соответствии со Статьей 21.3.1 ОУК, Директор
проекта должен либо вернуть один экземпляр
этого документа Поставщику с надписью,
свидетельствующей о его утверждении, либо
направить Поставщику письменное уведомление о
своем несогласии с этим документом и указать
причины такого несогласия и предлагаемые
поправки. Если Директор проекта не примет таких
мер в течение четырнадцати (14) дней, то
считается, что он утвердил этот документ.
21.3.3 Директор проекта может отказать в утверждении
какого-либо документа только на том основании,
что
этот
документ
не
соответствует
определенному положению Контракта или
противоречит добротной практике, принятой в
данной отрасли.
21.3.4 Если Директор проекта отказывается утвердить
документ, Поставщик должен исправить его и
повторно направить на утверждение Директора
проекта в соответствии со Статьей 21.3.2 ОУК.
Если Директор проекта утверждает документ при
условии внесения в него соответствующего
изменения (изменений), Поставщик должен внести
необходимое изменение (изменения), после чего
Раздел IV. Общие условия контракта
51
документ считается утвержденным, если только он
не подпадает под положения Статьи 21.3.5 ОУК.
Действия, описанные в Статьях с 21.3.2 по 21.3.4
ОУК, повторяются в установленном порядке до
тех пор, пока Директор проекта не утвердит
соответствующие документы.
21.3.5 Если между Покупателем и Поставщиком
возникает разногласие в связи или в результате
отказа Директора проекта утвердить какой-либо
документ и/или какую-либо поправку (поправки) к
документ, и стороны не могут урегулировать этот
спор в течение разумного периода времени, то в
том случае, когда в Контрактном соглашении
предусмотрен Третейский судья и указано его имя,
это разногласие может быть направлено
Третейскому судье для принятия решения в
соответствии со Статьей 6.1 ОУК (Третейский
судья). Если спор направляется Третейскому
судье,
Директор
проекта
дает
указания
относительно того, следует ли продолжать
выполнение Контракта, и если да, то каким
образом. Поставщик продолжает выполнять
Контракт в соответствии с указаниями Директора
проекта при условии, что, если Третейский судья
поддержит в споре позицию Поставщика и если
Покупатель не направит уведомления согласно
Статье 6.1.2 ОУК, то Покупатель должен
возместить Поставщику любые дополнительные
расходы, понесенные в связи выполнением таких
указаний Директора проекта, а Поставщик
освобождается от ответственности, связанной с
этим спором и выполнением этих указаний в том
объеме, в каком это определит Третейский судья.
При этом Дата приемки в эксплуатацию
соответственно переносится на более поздний
срок.
21.3.6 Утверждение Директором проекта документа,
представленного
Поставщиком
(будь-то
с
изменениями или без них), не освобождает
Поставщика
от
ответственности,
которая
возлагается на него какими-либо положениями
Контракта, за исключением ответственности,
возникающей в результате любой последующей
неполадки,
обусловленной
изменениями,
внесенными по требованию Директора проекта,
Раздел IV. Общие условия контракта
52
или неточностью письменной информации,
предоставленной Поставщику самим Покупателем
или от его имени.
21.3.7 Поставщик не должен отклоняться от каких-либо
утвержденных документов без предварительного
представления
Директору
проекта
скорректированного документа и получения
согласия Директора проекта с этим документом в
соответствии с положениями настоящей Статьи
21.3 ОУК. Если Директор проекта потребует
внести какое-либо изменение в уже утвержденный
документ и/или какой-либо документ, основой
которого является такой утвержденный документ,
это требование подпадает под положения Статьи
39 ОУК (Изменение Системы).
22. Закупка,
поставка и
транспортировк
а
22.1 При
условии
соблюдения
Покупателем
своих
обязательств по Статьям 10 и 14 ОУК, Поставщик
оперативно и организованно изготавливает или закупает
и
доставляет
на
Проектную
площадку
все
Информационные технологии, Материалы и прочие
Товары.
22.2 Доставка Информационных технологий, Материалов и
прочих Товаров осуществляется Поставщиком в
соответствии с Техническими требованиями.
22.3 Досрочная или частичная доставка требует однозначного
письменного согласия Покупателя, причем Покупатель
не должен безосновательно отказывать в таком согласии.
22.4 Транспортировка
22.4.1Поставщик обеспечивает упаковку Товаров,
необходимую для того, чтобы предотвратить их
повреждение или порчу в процессе транспортировки.
Внешняя и внутренняя упаковки и маркировка, а
также документация внутри и снаружи тары должны
строго
соответствовать
указаниям,
которые
Покупатель дал Поставщику.
22.4.2 Поставщик
несет
ответственность
за
транспортировку Товаров до Проектных площадок
и связанные с этим расходы в соответствии с
условиями, изложенными при определении цен в
Таблицах цен, включая условия соответствующих
ИНКОТЕРМС.
Раздел IV. Общие условия контракта
53
22.4.3 Если в СУК нет иных указаний, Поставщик по
своему усмотрению обеспечивает транспортировку
силами операторов, зарегистрированных в любой
правомочной стране, и оформляет страхование в
любой правомочной стране происхождения.
22.5 Если в СУК нет иных указаний, Поставщик должен
предоставить
Покупателю
перечисленные
далее
отгрузочные и прочие документы:
22.5.1
Для Товаров, поставляемых из-за рубежа:
После
отправки
Поставщик
направляет
Покупателю и страховой компании, с которой
Поставщик заключил договор страхования груза –
по телексу, телеграфу, телефаксу, электронной
почте или системе ЭОИ – уведомление с
подробным описанием отправленной партии груза.
Поставщик незамедлительно высылает Покупателю
– по почте или с курьером, в зависимости от
обстоятельств – перечисленные далее документы, с
копией страховой компании:
(a)
два экземпляра счета-фактуры Поставщика с
описанием Товаров и
указанием их
количества, цены единицы продукции и
общей стоимости;
(b)
обычные транспортные документы;
(c)
страховое свидетельство;
(d)
сертификат(ы) происхождения; и
(e)
расчетное время и пункт прибытия груза в
Страну Покупателя, а также на место.
22.5.2 Для
местных
Товаров
(т.е.
Товаров,
поставляемых с территории Страны Покупателя):
После
отправки
Поставщик
направляет
Покупателю – по телексу, телеграфу, телефаксу,
электронной почте или системе ЭОИ –
уведомление
с
подробным
описанием
отправленной
партии
груза.
Поставщик
незамедлительно высылает Покупателю – по почте
или с курьером, в зависимости от обстоятельств –
перечисленные далее документы:
Раздел IV. Общие условия контракта
54
(a)
два экземпляра счета-фактуры Поставщика с
описанием Товаров
и
указанием их
количества, цены единицы продукции и
общей стоимости;
(b)
транспортную накладную, железнодорожную
или автогрузовую квитанцию;
(c)
страховое свидетельство;
(d)
сертификат(ы) происхождения; и
(e)
расчетное время прибытия на место.
22.6 Таможенное оформление
23. Модернизация
продукции
(a)
Покупатель несет ответственность за таможенное
оформление Товаров и связанные с этим расходы, с
учетом
конкретных
ИНКОТЕРМС,
распространяющихся на Товары, поставляемые в
Страну Покупателя из-за рубежа, в соответствии с
Таблицами цен, упомянутыми в Статье 2
Контрактного соглашения.
(b)
По просьбе Покупателя, Поставщик направляет в
Страну Покупателя своего представителя или
агента на весь период таможенного оформления
Товаров, поставляемых в Страну Покупателя из-за
рубежа. В случае, если таможенное оформление
задерживается не по вине Поставщика:
(i)
Поставщик имеет право на перенос Даты
приемки в эксплуатацию на более поздний
срок в соответствии со Статьей 40 ОУК;
(ii)
Цена контракта корректируется в целях
компенсации
Поставщику
любых
дополнительных расходов на хранение,
которые Поставщик может понести в
результате такой задержки.
23.1 Если в любой момент в ходе выполнения Контракта
Поставщик произведет техническое усовершенствование
Информационных
технологий,
первоначально
предложенных в конкурсном предложении Поставщика
и еще не доставленных, Поставщик обязан предложить
Покупателю самые последние версии имеющихся
Информационных
технологий,
обладающие
аналогичными
или
более
совершенными
Раздел IV. Общие условия контракта
55
характеристиками или функциями при тех же или более
низких
ценах
единицы
продукции,
как
это
предусмотрено в Статье 39 ОУК (Изменение Системы).
23.2 Кроме того, в любой момент времени в ходе выполнения
Контракта на поставку и установку еще не доставленных
Информационных технологий, Поставщик обязан
предоставить Покупателю любые ценовые скидки и
дополнительные
и/или
более
совершенные
вспомогательные услуги и средства, которые он
предлагает другим своим клиентам в Стране
Покупателя, как это предусмотрено в Статье 39 ОУК
(Изменение Системы).
23.3 В ходе выполнения Контракта Поставщик должен
предлагать Покупателю все новые версии, редакции и
модификации Стандартных программных продуктов, а
также
сопутствующей
документации
и
услуг
технической поддержки в течение тридцати (30) дней
после того, как Поставщик стал предоставлять их
другим своим клиентам в Стране Покупателя, и не
позднее чем через двенадцать (12) месяцев после их
появления в стране происхождения. Ни при каких
обстоятельствах цены на эти Программные продукты не
должны превышать цен, указанных Поставщиком в
Форме текущих расходов, приведенной в составе его
конкурсного предложения.
23.4 Если в СУК нет иных указаний, то в течение
Гарантийного периода Поставщик должен бесплатно
предоставлять Покупателю все новые версии, редакции
и модификации Стандартных программных продуктов,
используемых в рамках Системы в течение тридцати (30)
дней после того, как Поставщик стал предоставлять их
другим своим клиентам в Стране Покупателя, и не
позднее чем через двенадцать (12) месяцев после их
появления в стране происхождения Программных
продуктов.
23.5 Покупатель должен внедрять все новые версии,
редакции или модификации Программных продуктов в
течение восемнадцати (18) месяцев с момента получения
готовой к производству копии новой версии, редакции
или модификации при условии, что эта новая версия,
редакция или модификация не оказывает отрицательного
влияния на работу или показатели эффективности
Системы и не требует крупномасштабной переделки
Раздел IV. Общие условия контракта
56
Системы. В тех случаях, когда новая версия, редакция
или модификация оказывает отрицательное влияние на
работу или показатели эффективности Системы или
требует
крупномасштабной
переделки
Системы,
Поставщик должен по-прежнему поддерживать и
использовать старую версию или редакцию в течение
периода времени, необходимого для внедрения новой
версии, редакции или модификации. Ни при каких
обстоятельствах Поставщик не должен прекращать
поддержку или использование версии или редакции
Программного обеспечения раньше, чем через двадцать
четыре (24) месяца после того, как Покупатель получит
готовую к производству копию следующей версии,
редакции или модификации. Покупатель принимает все
разумные меры для того, чтобы в кратчайшие сроки
внедрить любую новую версию, редакцию или
модификацию (с учетом того, что использование старой
версии, редакции или модификации прекращается через
двадцать четыре месяца).
24. Реализация,
установка и
прочие услуги
24.1 Поставщик должен предоставлять все Услуги,
оговоренные в Контракте и Согласованном и
уточненном плане проекта, честно и на самом высоком
профессиональном уровне.
24.2 Цены за Услуги Поставщика, которые не включены в
Контракт, согласуются сторонами заблаговременно (в
том числе, любые цены, указанные Поставщиком в
Таблицах текущих расходов, приведенных в его
конкурсном предложении) и не должны превышать
действующие расценки на аналогичные услуги,
установленные Поставщиком для других покупателей в
Стране Покупателя.
25. Инспекция и
тестирование
25.1 Покупатель или его представитель имеет право
инспектировать и/или тестировать любые компоненты
Системы (как это указано в Технических требованиях),
чтобы убедиться в том, что они находятся в хорошем
рабочем состоянии и/или соответствуют Контракту в
пункте доставки и/или на Проектной площадке.
25.2 Покупатель или его представитель имеет право
присутствовать при любом такой инспекции и/или
тестировании компонентов при условии, что Покупатель
берет на себя все издержки и расходы, понесенные в
связи с таким присутствием, включая, без ограничения
нижеперечисленным, все гонорары, транспортные и
сопутствующие
расходы
инспекторов,
которые
Раздел IV. Общие условия контракта
57
производят инспекцию.
25.3 Если проинспектированные или протестированные
компоненты не соответствуют Контракту, Покупатель
может забраковать эти компоненты, а Поставщик
должен либо бесплатно заменить забракованные
компоненты, либо бесплатно внести необходимые
изменения для обеспечения соответствия Контракту.
25.4 Директор проекта может попросить Поставщика
провести
инспекцию
и/или
тестирование,
не
оговоренные в Контракте, при условии, что
обоснованные издержки и расходы Поставщика,
понесенные при проведении такой инспекции и/или
тестирования, будут включены в Цену контракта. Кроме
того, если такая инспекция и/или тестирование мешают
ходу работы над Системой и/или выполнению
Поставщиком других обязанностей в рамках Контракта,
это следует учесть при определении Даты приемки в
эксплуатацию, а также сроков выполнения таких других
обязанностей.
25.5 Если
между
сторонами
возникает
какое-либо
разногласие в связи или в результате проведения
инспекции и/или по поводу какого-либо компонента,
подлежащего включению в Систему, и стороны не могут
миролюбиво разрешить это разногласие в течение
разумного периода времени, то любая сторона может
прибегнуть к процедуре, предусмотренной в Статье 6
ОУК (Урегулирование споров), начиная с вынесения
вопроса на рассмотрение Третейского судьи, если
Третейский Судья предусмотрен и его имя указано в
Контрактном соглашении.
26. Установка
Системы
26.1 Как только Поставщик решит, что Система или любая
Подсистема доставлена, Подготовлена к вводу в
эксплуатацию и доведена до стадии Приемки в
эксплуатацию и проведения Приемочных испытаний в
соответствии с Техническими требованиями, СУК и
Согласованным и уточненным планом проекта,
Поставщик
должен
направить
Покупателю
соответствующее письменное уведомление.
26.2 В течение четырнадцати (14) дней после того, как
Поставщик направит уведомление в соответствии со
Статьей ОУК 26.1, Директор проекта должен либо
выдать Сертификат установки по форме, приведенной в
разделе “Образцы форм” Документации для торгов,
Раздел IV. Общие условия контракта
58
который должен свидетельствовать о том, что Установка
Системы или ее крупной составной части, или
Подсистемы (если согласно СУК для Статьи 27.2.1 ОУК
предусмотрена возможность Приемки Системы по
базовым компонентам или Подсистемам) была
завершена к наступлению срока, когда Поставщик
направил уведомление в соответствии со Статьей ОУК
26.1, либо направить Поставщику письменное
уведомление о наличии каких-либо дефектов и/или
недостатков,
включая,
без
ограничения
нижеперечисленным,
дефекты
или
недостатки,
касающиеся взаимной совместимости или интеграции
различных частей и/или Подсистем, составляющих
Систему. Поставщик должен принять все разумные
меры для того, чтобы оперативно устранить любой
дефект и/или недостаток, отмеченный Директором
проекта в уведомлении Поставщику. Затем Поставщик
должен оперативно провести повторное тестирование
Системы или Подсистемы и, если, по мнению
Поставщика, Система или Подсистема готова к Вводу в
эксплуатацию и проведению Приемочных испытаний,
направить Покупателю письменное уведомление в
соответствии со Статьей ОУК 26.1. Процедуры,
изложенные в Статье ОУК 26.2, повторяются по мере
необходимости, до тех пор, пока не будет выдан
Сертификат установки.
26.3 Если Директор проекта не выдает Сертификата
установки и не сообщает Поставщику о дефектах и/или
недостатках в течение четырнадцати (14) дней после
получения уведомления Поставщика, направленного в
соответствии со Статьей ОУК 26.1, или если Покупатель
начинает эксплуатировать Систему или Подсистему в
рабочем режиме, то Установка Системы (или
Подсистемы) считается успешно завершенной в день
направления уведомления Поставщика или повторного
уведомления Поставщика, или в день, когда Покупатель
приступил к эксплуатации Системы в рабочем режиме, в
зависимости от обстоятельств.
Раздел IV. Общие условия контракта
27. Ввод и
Приемка в
эксплуатацию
59
27.1 Ввод в эксплуатацию
27.1.1 Ввод в эксплуатацию Система (или Подсистемы,
если это оговорено в СУК для Статьи 27.2.1 ОУК)
должно быть начато Поставщиком:
(a)
как только Директор проекта выдаст
Сертификат установки в соответствии со
Статьей 26.2 ОУК; или
(b)
в соответствии с иными положениями
Технических условий или Согласованного и
уточненного плана проекта; или
(c)
как только Установка будет сочтена
завершенной в соответствии со Статьей 26.3
ОУК.
27.1.2 Покупатель
предоставляет
операторов
и
технический персонал, а также все материалы и
информацию, необходимые для того, чтобы
Поставщик мог выполнить свои обязанности в
отношении Ввода в эксплуатацию.
Эксплуатация
Системы
или
Подсистемы
(Подсистем) в рабочем режиме не должна
начинаться до начала официальных Приемочных
испытаний.
27.2 Приемочные испытания
27.2.1 Приемочные испытания (а также повторное
проведение таких испытаний) являются, прежде
всего, обязанностью Покупателя (в соответствии
со Статьей 10.9 ОУК), однако проводятся в самом
тесном сотрудничестве с Поставщиком в период
Ввода в эксплуатацию Системы (или базовых
компонентов или Подсистемы [Подсистем], если
это оговорено в СУК и подтверждено
Техническими требованиями), чтобы убедиться в
том, что Система (или крупная составная часть,
или Подсистема [Подсистемы]) соответствует
Техническим
требованиям
и
показателям
эффективности,
указанным
в
конкурсном
предложении
Поставщика,
включая,
без
ограничения нижеперечисленным, требования
функциональной и технической эффективности.
Приемочные испытания в период Ввода в
Раздел IV. Общие условия контракта
60
эксплуатацию проводятся так, как указано в СУК,
Технических требованиях и/или Согласованном и
уточненном плане проекта.
По
усмотрению
Покупателя
Приемочные
испытания могут также проходить замещающие
Товары, модификации и новые версии, а также
Товары, дополнительно включенные в Систему
или модифицированные на месте уже после
завершения Приемочных испытаний Системы.
27.2.2 Если по вине Покупателя Приемочные испытания
Системы (или Подсистемы [Подсистем], или
базовых компонентов согласно СУК для Статьи
27.2.1 ОУК) не могут успешно завершиться в
течение периода времени, указанного в СУК,
начиная со дня Установки, или любого иного
периода времени, согласованного Покупателем и
Поставщиком в письменном виде, считается, что
Поставщик выполнил свои обязательства в части
соблюдения технических и функциональных
требований, изложенных в Технических условиях,
СУК и/или Согласованном и уточненном плане
проекта, и в этом случае положения Статей 28.2 и
28.3 ОУК не применимы.
27.3 Приемка в эксплуатацию
27.3.1 С учетом Статьи 27.4 ОУК (Частичная приемка)
Система принимается в эксплуатацию, если:
(a) Приемочные испытания успешно завершились
в соответствии с Техническими требованиями
и/или
положениями
СУК
и/или
Согласованным и уточненным планом
проекта; или
(b) Приемочные испытания не были успешно
завершены или не были проведены по вине
Покупателя в течение определенного периода
времени, начиная со дня Установки, или
любого иного согласованного периода
времени, как это указано выше в Статье 27.2.2
ОУК; или
(c) Покупатель эксплуатировал или использовал
Систему в течение шестидесяти (60)
Раздел IV. Общие условия контракта
61
последовательных дней. Если Система пущена
в эксплуатацию или начинает использоваться
таким образом, Поставщик должен направить
Покупателю
уведомление
и
задокументировать
такое
использование
Системы.
27.3.2 После того, как произошло любое из событий,
описанных в Статье 27.3.1 ОУК, Поставщик может
в любое время направить уведомление Директору
проекта с просьбой о выдаче Сертификата
приемки в эксплуатацию.
27.3.3 После проведения консультаций с Покупателем и
в течение четырнадцати (14) дней после получения
уведомления Поставщика Директор проекта
должен:
(a)
выдать
Сертификат
эксплуатацию; или
приемки
в
(b)
письменно уведомить Поставщика о какомлибо дефекте или недостатке, или иной
причине
отрицательного
результата
Приемочных испытаний; или
(c)
выдать Сертификат приемки в эксплуатацию
при возникновении ситуации, описанной в
Статье 27.3.1 (b) ОУК.
27.3.4 Поставщик делает все возможное для того, чтобы
оперативно устранить любой дефект и/или
недостаток, и/или иные причины отрицательного
результата Приемочных испытаний, которые
Директор проекта отметил в уведомлении
Поставщику. Как только Поставщик исправит эту
ситуацию, он должен уведомить об этом
Покупателя, и Покупатель в самом тесном
сотрудничестве с Поставщиком должен принять
все разумные меры для того, чтобы оперативно
провести повторное тестирование Системы или
Подсистемы. После успешного завершения
Приемочных испытаний Поставщик направляет
Покупателю уведомление с просьбой о выдаче
Сертификата приемки в эксплуатацию в
соответствии со Статьей 27.3.3 ОУК. После этого
Покупатель
должен
выдать
Поставщику
Сертификат
приемки
в
эксплуатацию
в
Раздел IV. Общие условия контракта
62
соответствии со Статьей 27.3.3 (a) ОУК или
уведомить Поставщика о других дефектах,
недостатках или иных причинах отрицательного
результата Приемочных испытаний. Процедура,
описанная в настоящей Статье 27.3.4 ОУК,
повторяется, по мере необходимости, до тех пор,
пока не будет выдан Сертификат приемки в
эксплуатацию.
27.3.5 Если Система или Подсистема не может успешно
пройти Приемочные испытания в соответствии со
Статьей 27.2 ОУК, то либо:
(a)
Покупатель
рассматривает
вопрос
о
расторжении Контракта на основании
Статьи 41.2.2 ОУК,
либо
(b)
если Приемка в эксплуатацию не может
состояться в течение оговоренного периода
времени из-за того, что Покупатель не
выполнил свои обязательства по Контракту,
то считается, что Поставщик выполнил свои
обязательства
в
части
соблюдения
соответствующих
технических
и
функциональных требований Контракта. И в
этом случае положения Статьи 30.3 ОУК не
применимы.
27.3.6 Если Директор проекта не выдает Сертификата
приемки в эксплуатацию или не направляет
Поставщику письменного сообщения о веских
причинах отказа в выдаче Сертификата приемки в
эксплуатацию в течение четырнадцати (14) дней
после получения уведомления Поставщика, то
Система (или Подсистема) считается принятой в
эксплуатацию в день направления указанного
уведомления Поставщика.
27.4 Частичная приемка
27.4.1 Если это оговорено в СУК для Статьи 27.2.1
ОУК, Установка и Ввод в эксплуатацию
осуществляются отдельно для каждой указанной
крупной составной части или Подсистемы
Системы. В этом случае положения Контракта,
касающиеся Установки и Ввода в эксплуатацию,
Раздел IV. Общие условия контракта
63
включая
Приемочные
испытания,
распространяются на каждую такую крупную
составную
часть
или
Подсистему
в
индивидуальном
порядке,
и
Сертификат
(Сертификаты) приемки в эксплуатацию выдается
(выдаются), соответственно, для каждой крупной
составной части или Подсистемы Системы с
учетом ограничений, перечисленных в Статье
27.4.2 ОУК.
27.4.2 Выдача Сертификатов приемки в эксплуатацию
для отдельных крупных составных частей или
Подсистем в соответствии со Статьей 27.4.1 ОУК
не освобождает Поставщика от обязанности
получить Сертификат приемки в эксплуатацию
всей Системы как единого целого (если это
оговорено в СУК для Статей 12.1 и 27.2.1) после
того, как будут поставлены, установлены,
протестированы и введены в эксплуатацию все
крупные составные части и Подсистемы.
27.4.3 Что касается мелких составных частей Системы,
которые, по своему характеру, не требуют Ввода в
эксплуатацию или проведения Приемочных
испытаний (например, мелкие приспособления,
принадлежности, работы на площадке и т.д.), то
Директор проекта должен выдать для них
Сертификат эксплуатационной приемки в течение
четырнадцати (14) дней после того, как эти
приспособления и/или принадлежности были
доставлены и/или установлены, или работы на
площадке были завершены. Тем не менее,
Поставщик должен принять все разумные меры
для того, чтобы оперативно устранить любые
дефекты
или
недостатки,
обнаруженные
Покупателем или Поставщиком в этих мелких
составных частях.
F. ГАРАНТИИ И ОТВЕТСТВЕННОСТЬ
28. Гарантия
соблюдения
сроков Приемки
в эксплуатацию
28.1 Поставщик гарантирует, что он завершит поставку,
Установку, Ввод в эксплуатацию и обеспечит доведение
до стадии Приемки в эксплуатацию Системы (или
Подсистем согласно СУК для Статьи 27.2.1 ОУК) к
наступлению сроков, указанных в Графике реализации,
Раздел IV. Общие условия контракта
64
приведенном в разделе “Технические требования”, и/или
в Согласованном и уточненном плане проекта, в
соответствии со Статьей 8.2 ОУК, или в течение
дополнительного периода времени, на который
Поставщик имеет право согласно Статье 40 ОУК
(Перенос Даты приемки в эксплуатацию на более
поздний срок).
28.2 Если Поставщик не может обеспечить поставку,
установку, ввод в эксплуатацию и доведение до стадии
Приемки в эксплуатацию Системы (или Подсистем
согласно СУК для Статьи 27.2.1 ОУК) к наступлению
срока Приемки в эксплуатацию, указанного в Графике
реализации, приведенном в разделе “Технические
требования”, или в Согласованном и уточненном плане
проекта, или в течение дополнительного периода
времени, заблаговременно предоставленного для
доведения до стадии Приемки в эксплуатацию согласно
Статье 40 ОУК (Перенос Даты приемки в эксплуатацию
на более поздний срок), то Поставщик выплачивает
Покупателю неустойку по ставке, указанной в СУК, в
виде процента от Цены контракта или соответствующей
части Цены контракта (если какая-то Подсистема не
доведена до стадии Приемки в эксплуатацию). Общая
сумма такой неустойки ни при каких обстоятельствах не
может превышать сумму, указанную в СУК
(“Максимум”). Как только этот Максимум будет
достигнут, Покупатель может рассмотреть вопрос о
расторжении Контракта на основании Статьи 41.2.2
ОУК.
28.3 Если в СУК нет иных указаний, неустойка,
выплачиваемая в соответствии со Статьей 28.2 ОУК,
распространяется только на те случаи, когда Система (и
Подсистемы) не доведена до стадии Приемки в
эксплуатацию, предусмотренной в Графике реализации,
приведенном в разделе “Технические требования”, и/или
в Согласованном и уточненном плане проекта. Тем не
менее, настоящая Статья 28.3 не ограничивает никаких
иных прав или средств защиты, которые Покупатель
может иметь по Контракту в случае других задержек.
28.4 Если Покупатель получает неустойку за Систему (или
Подсистему), Поставщик в дальнейшем не несет
никакой ответственности перед Покупателем в части
соблюдения
сроков
Приемки
Системы
(или
Подсистемы) в эксплуатацию. Однако уплата неустойки
не освобождает Поставщика от обязанности завершения
Раздел IV. Общие условия контракта
Системы
или
иных
обязанностей
ответственности в рамках Контракта.
29.Ответственность
за дефекты
65
и
видов
29.1 Поставщик гарантирует, что Система, включая все
Информационные технологии, Материалы и прочие
поставляемые Товары и предоставляемые Услуги, не
имеет дефектов проекта, конструкции, Материалов и
качества изготовления, из-за которых Система и/или
любая из ее составных частей не будет соответствовать
Техническим требованиям, или дефектов, которые
существенным образом ограничивают эффективность,
надежность или возможность расширения Системы
и/или Подсистем. Исключения из настоящей гарантии
и/или ограничения настоящей гарантии (если таковые
имеются), касающиеся Программных продуктов (или
категорий Программных продуктов), будут такими, как
оговорено в СУК. Коммерческие гарантии на
продукцию, поставляемую в рамках Контракта,
действительны в том объеме, в каком они не
противоречат положениям настоящего Контракта.
29.2 Поставщик также гарантирует, что Информационные
технологии, Материалы и прочие Товары, поставляемые
в
рамках
Контракта,
являются
новыми,
неиспользованными и учитывают все новейшие
достижения в области проектирования, которые
оказывают существенное влияние на способность
Системы или Подсистемы отвечать Техническим
требованиям.
29.3 Кроме того, Поставщик гарантирует, что: (i) все Товары,
входящие в состав Системы, относятся к группам
продуктов, которые Поставщик или Субподрядчики
выпускают в настоящее время, (ii) они уже выпускались
на рынок, и (iii) конкретные позиции, перечисленные в
СУК (если таковые имеются), находились на рынке не
менее минимально приемлемого периода времени,
оговоренного в СУК.
29.4 Гарантийный период начинается в день Приемки в
эксплуатацию Системы (или любой крупной составной
части, или Подсистемы, для которых Контракт
предусматривает отдельную Приемку в эксплуатацию) и
продолжается в течение времени, оговоренного в СУК.
29.5 Если в течение Гарантийного периода в проекте,
конструкции, Материалах или качестве изготовления
Раздел IV. Общие условия контракта
66
будет
обнаружен
какой-либо
дефект
проекта,
конструкции, Материалов или качества изготовления
Информационных технологий и прочих Товаров или
Услуг, поставленных/предоставленных Поставщиком,
как это указано в Статье 29.1 ОУК, Поставщик, проведя
консультации и договорившись с Покупателем
относительно надлежащих мер устранения дефекта,
должен незамедлительно и исключительно за свой счет
произвести ремонт, замену или иным образом исправить
(в зависимости от того, какое решение примет сам
Поставщик) этот дефект и устранить любой ущерб,
нанесенный Системе этим дефектом. Любые дефектные
Информационные технологии или иные Товары,
которые заменил Поставщик, остаются в собственности
Поставщика.
29.6 Поставщик не несет ответственности за ремонт, замену
или исправление каких-либо дефектов или устранение
ущерба Системе, возникших вследствие или в результате
любой из перечисленных далее причин:
(a) Покупатель
неправильно
обслуживает Систему;
эксплуатирует
или
(b) обычный износ;
(c) использование Системы вместе продукцией, которая
не
была
предоставлена
Поставщиком,
за
исключением случаев, когда такая продукция
определена в Технических требованиях или одобрена
Поставщиком; или
(d) Покупатель или третье лицо внесли в Систему
изменения, не согласованные с Поставщиком.
29.7 Обязанности Поставщика, изложенные в настоящей
Статье 29 ОУК, не распространяются на:
(a) материалы, которые обычно расходуются в процессе
работы или имеют стандартный срок службы короче
Гарантийного периода; или
(b) любые технические проекты, спецификации или
прочие данные, предоставленные или заданные
самим Покупателем или от его имени, или любые
случаи,
когда
Поставщик
отказался
от
ответственности на основании Статьи 21.1.2 ОУК.
29.8 После
обнаружения
такого
дефекта
Покупатель
Раздел IV. Общие условия контракта
67
незамедлительно направляет Поставщику уведомление с
указанием характера дефекта и изложением всех
имеющихся доказательств. Покупатель создает все
необходимые условия для того, чтобы Поставщик мог
ознакомиться с дефектом. Покупатель предоставляет
Поставщику необходимый доступ к Системе и на
площадку, чтобы Поставщик мог выполнить свои
обязанности, предусмотренные настоящей Статьей 29
ОУК.
29.9 С согласия Покупателя Поставщик может вывезти с
площадки любые неисправные Информационные
технологии и прочие дефектные Товары, если характер
дефекта и/или ущерба, который он нанес Системе, не
позволяет оперативно произвести ремонт на месте. Если
ремонт, замена или исправление дефекта могут оказать
отрицательное влияние на эффективность Системы,
Покупатель может направить уведомление Поставщику
с требованием о том, чтобы сразу после завершения
ремонтных работ Поставщик провел испытания
дефектной детали, и Поставщик должен провести такие
испытания в указанные сроки.
Если деталь не проходит испытания, Поставщик
осуществляет
повторный
ремонт,
замену
или
исправление (в зависимости от обстоятельств) до тех
пор, пока эта деталь Системы не пройдет испытания.
Такие испытания должны быть согласованы между
Покупателем и Поставщиком.
29.10 Если Поставщик не приступает к работе по
исправлению дефекта или устранению ущерба,
нанесенного Системе этим дефектом, в течение периода
времени, указанного в СУК, Покупатель, направив
Поставщику соответствующее уведомление, может
самостоятельно провести такую работу или передать ее
по договору третьему лицу (или лицам), и обоснованные
издержки, понесенные Покупателем в связи с
проведением этой работы, должны быть оплачены
Поставщиком или могут быть удержаны Покупателем из
сумм, причитающихся Поставщику, или из Залогового
обеспечения выполнения контракта.
29.11 Если Систему или Подсистему нельзя использовать по
причине такого дефекта и/или из-за того, что
принимаются меры по его исправлению, Гарантийный
период Системы продлевается на срок, в течение
которого Покупатель не мог использовать Систему или
Раздел IV. Общие условия контракта
68
Подсистему из-за такого дефекта и/или его исправления.
29.12 Позиции, поставленные взамен дефектных деталей
Системы в течение Гарантийного периода, подпадают
под Гарантию ответственности за дефекты на всю
оставшуюся
часть
Гарантийного
периода,
распространяющегося на замененную деталь, или на три
(3) месяца, в зависимости от того, какой период длиннее.
29.13 По просьбе Покупателя и без ущерба для любых других
прав и средств защиты, которые Покупатель может
иметь по отношению к Поставщику в рамках Контракта,
Поставщик оказывает Покупателю всяческое содействие
в получении гарантийных или ремонтных услуг от
любых третьих лиц, являющихся производителями или
лицензиарами Товаров, входящих в состав Системы, с
которыми заключены договоры субподряда, включая,
без ограничения нижеперечисленным, переуступку или
передачу Покупателю любых гарантийных прав,
предоставленных Поставщику такими производителями
или лицензиарами.
30.Функциональны
е гарантии
30.1 Поставщик гарантирует, что после выдачи Сертификата
(Сертификатов) приемки в эксплуатацию Система
представляет собой законченное, комплексное решение
задач Покупателя, сформулированных в Технических
требованиях, и во всех остальных отношениях
соответствует Контракту. Поставщик подтверждает, что
порядок определения технического соответствия
Системы
требованиям
Контракта
регулируется
положениями Статьи 27 ОУК, которые касаются Ввода и
Приемки в эксплуатацию.
30.2 Если по вине Поставщика Система не соответствует
Техническим требованиям или не отвечает положениям
Контракта во всех остальных отношениях, Поставщик за
свой счет должен произвести необходимое изменение,
модификацию и/или расширение Системы, чтобы
обеспечить соответствие Техническим требованиям и
выполнение всех функциональных норм и показателей
работы. После завершения необходимого изменения,
модификации или расширения Системы Поставщик
направляет Покупателю соответствующее уведомление
и просит Покупателя провести повторные Приемочные
испытания, чтобы обеспечить Приемку Системы в
эксплуатацию.
30.3 Если Система (или Подсистема [Подсистемы]) не была
Раздел IV. Общие условия контракта
69
доведена до стадии Приемки в эксплуатацию,
Покупатель может рассмотреть вопрос о расторжении
Контракта на основании Статьи 41.2.2 ОУК и удержании
предоставленного Поставщиком Залогового обеспечения
выполнения контракта на основании Статьи 13.3 ОУК в
целях компенсации дополнительных расходов и
задержек, которые могут возникнуть в связи с тем, что
Система (или Подсистема [Подсистемы]) не была
доведена до стадии Приемки в эксплуатацию.
31. Гарантия
соблюдения
Прав
интеллектуальн
ой
собственности
31.1 Поставщик настоящим заявляет и гарантирует, что:
(a)
Система, в том виде, в каком она была поставлена,
установлена, протестирована и принята,
(b)
использование
Контрактом, и
(c)
копирование
Программных
Материалов, предоставленных
основании Контракта,
Системы
в
соответствии
с
продуктов
Покупателю
и
на
не нарушают и не будут нарушать никаких Прав
интеллектуальной
собственности,
принадлежащих
какой-либо третьей стороне, и что сам Поставщик
обладает всеми необходимыми правами или за свой счет
письменно оформил передачу всех прав и получение
прочих разрешений, необходимых для переуступки прав,
получения лицензий и иной передачи Прав
интеллектуальной
собственности
и
гарантий,
оговоренных в контракте, а также для того, чтобы
Покупатель имел или осуществлял все предусмотренные
Контрактом Права интеллектуальной собственности.
Без ограничения нижеперечисленным, Поставщик
должен оформить все необходимые письменные
соглашения, разрешения и передачу прав своих
сотрудников и прочих лиц или организаций, которые
привлекались для разработки Системы.
32. Возмещение
ущерба от
нарушения
Прав
интеллектуальн
ой
собственности
32.1 Поставщик обеспечивает Покупателю, его сотрудникам
и должностным лицам возмещение ущерба и защиту от
любых и всех убытков, обязательств и расходов
(включая убытки, обязательства и расходы, связанные с
оспариванием иска, утверждающего существование
таких обязательств), которые Покупатель или его
сотрудники или должностные лица могут понести в
результате реального или утверждаемого нарушения
каких-либо Прав интеллектуальной собственности,
Раздел IV. Общие условия контракта
70
возникшего вследствие:
(a)
установки
Системы
Поставщиком
или
использования Системы (в том числе, Материалов)
в стране, где расположена площадка;
(b)
копирования
Программных
Материалов, предоставленных
соответствии с соглашением; и
(c)
продажи продуктов, произведенных Системой, в
какой-либо стране, за исключением случаев, когда
такие убытки, обязательства или расходы
возникают в результате нарушения Покупателем
Статьи 32.2 ОУК.
продуктов
и
Поставщиком в
32.2 Такое возмещение ущерба не распространяется на
случаи использования Системы (включая Материалы)
для каких-либо целей, кроме тех, что указаны в
Контракте или обоснованно вытекают из него, на любые
нарушения прав, обусловленные использованием
Системы, или любые продукты, произведенные
Системой совместно или в сочетании с любыми другими
товарами или услугами, которые не были предоставлены
Поставщиком, если нарушение прав возникло в
результате такого совмещения или сочетания, а не в
результате использования Системы как таковой.
32.3 Такое возмещение ущерба не распространяется также на
случаи исков о нарушении прав, которые:
(a)
предъявляются
материнской, дочерней
аффилированной организацией Покупателя;
или
(b)
являются прямым следствием технического
проекта,
предписанного
Покупателем
в
Технических требованиях, и Поставщик в своем
конкурсном предложении надлежащим образом
отметил возможность возникновения такого
нарушения прав; или
(c)
обусловлены тем, что Покупатель или иное лицо,
не являющееся Поставщиком или лицом, которое
уполномочено Поставщиком, внесли изменения в
Систему, включая Материалы.
32.4 Если
против
Покупателя
начато
судебное
разбирательство или ему предъявлен иск в связи с
вопросами, упомянутыми в Статье 32.1 ОУК,
Раздел IV. Общие условия контракта
71
Покупатель
должен
незамедлительно
уведомить
Поставщика о таком судебном разбирательстве или иске,
а Поставщик может за свой счет и от имени Покупателя
принять участие в этом судебном разбирательстве или
рассмотрении иска, а также в любых переговорах по
урегулированию этого разбирательства или иска.
Если Поставщик в течение двадцати восьми (28) дней
после получения упомянутого выше уведомления не
уведомит Покупателя о своем намерении принять
участие в судебном разбирательстве или рассмотрении
иска, то Покупатель имеет право самостоятельно
участвовать в таком судебном разбирательстве или
рассмотрении иска. За исключением случаев, когда
Поставщик не направил Покупателю уведомления в
течение двадцати восьми (28) дней, Покупатель не
должен делать никаких признаний, которые могут
причинить вред защите в процессе такого судебного
разбирательства или рассмотрения иска. По просьбе
Поставщика, Покупатель должен оказать Поставщику
любую возможную помощь в процессе такого судебного
разбирательства или рассмотрения иска, а Поставщик
должен возместить Покупателю все обоснованные
расходы, понесенные в этой связи.
32.5 Покупатель обеспечивает Поставщику, его сотрудникам,
должностным лицам и Субподрядчикам возмещение
ущерба и защиту от любых и всех убытков, обязательств
и расходов (включая убытки, обязательства и расходы,
связанные с оспариванием иска, утверждающего
существование таких обязательств), которые Поставщик
или его сотрудники, должностные лица или
Субподрядчики могут понести в результате реального
или утверждаемого нарушения каких-либо Прав
интеллектуальной
собственности,
возникшего
вследствие или в связи с любыми техническими
проектами, данными, чертежами, спецификациями или
иными документами или материалами, которые были
предоставлены Поставщику в рамках настоящего
Контракта самим Покупателем или любыми лицами
(кроме Поставщика), нанятыми Покупателем по
договору, за исключением случаев, когда такие убытки,
обязательства и расходы возникают в результате
нарушения Поставщиком Статьи 32.8 ОУК.
32.6 Такое возмещение не будет распространяться на:
Раздел IV. Общие условия контракта
72
(a)
случаи использования этих технических проектов,
данных, чертежей, спецификаций или иных
документов или материалов для каких-либо целей,
кроме тех, что указаны в Контракте или
обоснованно вытекают из него,
(b)
на любые нарушения прав, обусловленные
использованием этих технических проектов,
данных, чертежей, спецификаций или иных
документов или материалов, или продуктов,
произведенными с их помощью совместно или в
сочетании с любыми другими Товарами или
Услугами, которые не были предоставлены
Покупателем
или
иным
лицом,
нанятым
Покупателем по договору, если нарушение прав
возникло в результате такого совмещения или
сочетания, а не в результате использования этих
технических
проектов,
данных,
чертежей,
спецификаций или иных документов или
материалов как таковых.
32.7 Такое возмещение ущерба не распространяется также на
следующие случаи:
(a)
иск о нарушении прав предъявлен материнской,
дочерней или аффилированной организацией
Поставщика;
(b)
иск о нарушении прав является следствием того,
что Поставщик или любое лицо, нанятое
Поставщиком по договору, внесли изменения в эти
технические
проекты,
данные,
чертежи,
спецификации
или
иные
документы
или
материалы,
которые
были
предоставлены
Поставщику самим Покупателем или любыми
лицами, нанятыми Покупателем по договору.
32.8 Если
против
Поставщика
начато
судебное
разбирательство или ему предъявлен иск в связи с
вопросами, упомянутыми в Статье 32.5 ОУК, Поставщик
должен незамедлительно уведомить Покупателя о таком
судебном разбирательстве или иске, а Покупатель может
за свой счет и от имени Поставщика принять участие в
этом судебном разбирательстве или рассмотрении иска,
а также в любых переговорах по урегулированию этого
разбирательства или иска. Если Покупатель в течение
двадцати восьми (28) дней после получения упомянутого
выше уведомления не уведомит Поставщика о своем
Раздел IV. Общие условия контракта
73
намерении принять участие в судебном разбирательстве
или рассмотрении иска, то Поставщик имеет право
самостоятельно участвовать в таком судебном
разбирательстве
или
рассмотрении
иска.
За
исключением случаев, когда Покупатель не направил
Покупателю уведомления в течение двадцати восьми
(28) дней, Поставщик не должен делать никаких
признаний, которые могут причинить вред защите в
процессе такого судебного разбирательства или
рассмотрения иска. По просьбе Покупателя, Поставщик
должен оказать Покупателю любую возможную помощь
в процессе такого судебного разбирательства или
рассмотрения иска, а Покупатель должен возместить
Поставщику все обоснованные расходы, понесенные в
этой связи.
33. Пределы
ответственности
33.1 С учетом того, что нижеследующее не исключает и не
ограничивает никаких обязательств каждой стороны так,
чтобы
это
противоречило
применимому
законодательству:
(a)
(b)
Поставщик не несет перед Покупателем никакой
ответственности – будь-то по Контракту,
гражданскому праву или на иных основаниях – за
любые косвенные убытки или ущерб, утрату
возможности использования, утрату возможности
производства, упущенную прибыль или упущенные
проценты при условии, что такое освобождение от
ответственности не распространяется на какие-либо
обязанности Поставщика, касающиеся уплаты
неустойки Покупателю, и
совокупный объем ответственности Поставщика
перед Покупателем – будь-то по Контракту,
гражданскому праву или на иных основаниях – не
может превышать общей Цены контракта при
условии,
что
такое
ограничение
не
распространяется на обязанность Поставщика
возместить Покупателю ущерб, обусловленный
нарушением прав интеллектуальной собственности.
G. РАСПРЕДЕЛЕНИЕ РИСКОВ
34. Передача прав
собственности
34.1 За исключением Программных продуктов и Материалов,
право собственности на Информационные технологии и
прочие Товары переходит к Покупателю в момент
Раздел IV. Общие условия контракта
74
Доставки или в соответствии с иными условиями,
которые могут согласованы и оговорены в Контрактном
соглашении.
34.2 Право собственности на Программные продукты и
Материалы, предоставленные в рамках Контракта, и
условия их использования регулируются положениями
Статьи 15 ОУК (Авторские права), а также любыми
применимыми положениями Технических требований.
34.3 Право собственности на Оборудование Поставщика,
используемое Поставщиком и его Субподрядчиками в
связи с выполнением Контракта, остается у Поставщика
или его Субподрядчиков.
35. Уход за
Системой
35.1 После Доставки ответственность за содержание и
хранение Системы или Подсистем переходит к
Покупателю. Покупатель за свой счет компенсирует
любой урон или ущерб, которые могут быть нанесены
Системе или Подсистемам при любых обстоятельствах
после дня Доставки и до наступления дня Приемки
Системы или Подсистем в эксплуатацию, как это
предусмотрено в Статье 27 ОУК (Ввод и Приемка в
эксплуатацию), за исключением случаев, когда причиной
такого урона или ущерба являются действия или
бездействие Поставщика, его сотрудников или
Субподрядчиков.
35.2 Если Системе или любой части Системы нанесены урон
или ущерб, причинами которых являются:
(a) (насколько это относится к стране, где находится
Проектная площадка) ядерная реакция, ядерное
излучение, радиоактивное загрязнение, волна
сжатия, созданная самолетом или другим
летающим объектом, или иные события, которые
опытный подрядчик не может предугадать или
(если их можно предугадать) не может принять
никаких мер профилактики или застраховаться от
таких событий, поскольку такие риски обычно не
страхуются на страховом рынке и упоминаются в
страховом полисе, оформленном в соответствии со
Статьей 37 ОУК, как исключения общего
характера;
(b)
любое использование Системы или части Системы
Покупателем или третьей стороной не в
соответствии с Контрактом;
Раздел IV. Общие условия контракта
(c)
75
любое использование или учет каких-либо
технических проектов, данных или спецификаций,
предоставленных или разработанных самим
Покупателем или от его имени, или любой случай,
когда Поставщик отказался от ответственности на
основании Статьи 21.1.2 ОУК,
Покупатель должен выплатить Поставщику все
причитающиеся суммы за Систему или Подсистемы,
доведенные до стадии Приемки в эксплуатацию,
несмотря на то, что они могут быть утрачены,
разрушены или повреждены. Если Покупатель
направляет Поставщику письменную просьбу об
устранении нанесенного Покупателем урона или ущерба
Системе, Поставщик должен устранить этот урон или
ущерб за счет Покупателя в соответствии со Статьей 39
ОУК. Если Покупатель не направляет Поставщику
письменной просьбы об устранении нанесенного
Покупателем урона или ущерба Системе, он должен
либо запросить изменение в соответствии со Статьей 39
ОУК, чтобы исключить ту часть Системы, которая была
утрачена, разрушена или повреждена, либо – когда этот
урон или ущерб оказывают влияние на значительную
часть Системы – расторгнуть Контракт на основании
Статьи 41.1 ОУК.
35.3 Покупатель несет ответственность за любой урон или
ущерб,
нанесенный
Оборудованию
Поставщика,
которое, по распоряжению Покупателя, было размещено
в помещении Покупателя для выполнения обязанностей
Поставщика в рамках Контракта, за исключением
случаев, когда причиной такого урона или ущерба
являются действия или бездействие Поставщика, его
сотрудников или Субподрядчиков.
36. Утрата или
повреждение
имущества;
несчастный
случай или
травма на
производстве;
возмещение
ущерба
36.1 Поставщик и каждый Субподрядчик обязаны соблюдать
принятые в Стране Покупателя меры и действующие в
этой стране законы, касающиеся техники безопасности,
страхования, таможенного оформления и иммиграции.
36.2 С учетом положений Статьи 36.3 ОУК Поставщик
обеспечивает Покупателю, его сотрудникам и
должностным лицам возмещение ущерба и защиту от
любых и всех убытков, обязательств и расходов
(включая убытки, обязательства и расходы, связанные с
оспариванием иска, утверждающего существование
таких обязательств), которые Покупатель или его
Раздел IV. Общие условия контракта
76
сотрудники, или должностные лица могут понести в
связи с гибелью или травмой любого человека, или
утратой или повреждением любого имущества (кроме
Системы, независимо от того, принята она или нет) в
результате поставки, установки, тестирования Системы
и ее Ввода в эксплуатацию, а также в силу небрежности
Поставщика или его Субподрядчиков, или их
сотрудников, должностных лиц или агентов, за
исключением случаев, когда причиной травмы или
гибели человека или ущерба имуществу является
небрежность Покупателя, его подрядчиков, сотрудников,
должностных лиц или агентов.
36.3 Если
против
Покупателя
начато
судебное
разбирательство или ему предъявлен иск, в результате
которых на Поставщика может быть возложена
ответственность на основании Статьи 36.2 ОУК,
Покупатель
должен
незамедлительно
уведомить
Поставщика о таком судебном разбирательстве или иске,
и Поставщик может за свой счет и от имени Покупателя
принять участие в таком разбирательстве или
рассмотрении иска, а также в любых переговорах по
урегулированию этого разбирательства или иска. Если
Поставщик в течение двадцати восьми (28) дней после
получения упомянутого выше уведомления не уведомит
Покупателя о своем намерении принять участие в
судебном разбирательстве или рассмотрении иска, то
Покупатель имеет право самостоятельно участвовать в
таком судебном разбирательстве или рассмотрении иска.
За исключением случаев, когда Поставщик не направил
Покупателю уведомления в течение двадцати восьми
(28) дней, Покупатель не должен делать никаких
признаний, которые могут причинить вред защите в
процессе такого судебного разбирательства или
рассмотрения иска. По просьбе Поставщика, Покупатель
должен оказать Поставщику любую возможную помощь
в процессе такого судебного разбирательства или
рассмотрения иска, а Поставщик должен возместить
Покупателю все обоснованные расходы, понесенные в
этой связи.
36.4 Покупатель обеспечивает Поставщику, его сотрудникам,
должностным лицам и Субподрядчикам возмещение
ущерба и защиту от любых и всех убытков, обязательств
и расходов (включая убытки, обязательства и расходы,
связанные с оспариванием иска, утверждающего
существование таких обязательств), которые Поставщик
Раздел IV. Общие условия контракта
77
или его сотрудники, должностные лица или
Субподрядчики могут понести в связи с гибелью или
травмой любого человека, или утратой или
повреждением любого имущества Покупателя (кроме
Системы, еще не доведенной до стадии Приемки в
эксплуатацию) в результате пожара, взрыва или любых
иных опасностей, сверх суммы, компенсируемой за счет
страхования, оформленного в соответствии со Статьей
37 ОУК (Страхование) при условии, что причиной
такого пожара, взрыва или иных опасностей не является
какое-либо действие или бездействие Поставщика.
36.5 Если
против
Поставщика
начато
судебное
разбирательство или ему предъявлен иск, в результате
которых на Покупателя может быть возложена
ответственность на основании Статьи 36.4 ОУК,
Поставщик
должен
незамедлительно
уведомить
Покупателя о таком судебном разбирательстве или иске,
и Покупатель может за свой счет и от имени Поставщика
принять участие в таком судебном разбирательстве или
рассмотрении иска, а также в любых переговорах по
урегулированию этого разбирательства или иска. Если
Покупатель в течение двадцати восьми (28) дней после
получения упомянутого выше уведомления не уведомит
Поставщика о своем намерении принять участие в
судебном разбирательстве или рассмотрении иска, то
Поставщик имеет право самостоятельно участвовать в
таком судебном разбирательстве или рассмотрении иска.
За исключением случаев, когда Покупатель не направил
Поставщику уведомления в течение двадцати восьми
(28) дней, Поставщик не должен делать никаких
признаний, которые могут причинить вред защите в
процессе такого судебного разбирательства или
рассмотрения иска. По просьбе Покупателя, Поставщик
должен оказать Покупателю любую возможную помощь
в процессе такого судебного разбирательства или
рассмотрения иска, а Покупатель должен возместить
Поставщику все обоснованные расходы, понесенные в
этой связи.
36.6 Сторона, в пользу которой осуществляется возмещение
ущерба на основании настоящей Статьи 36 ОУК,
принимает все разумные меры для того, чтобы смягчить
любой нанесенный урон или ущерб. Если эта сторона не
принимает таких мер, обязательства второй стороны
соответствующим образом сокращаются.
Раздел IV. Общие условия контракта
37. Страхование
78
37.1 Поставщик за свой счет оформляет описанный далее
страховой пакет и сохраняет его в силе в течение всего
срока
выполнения
Контракта.
Кандидатуры
страховщиков и форма страховых полисов подлежат
согласованию с Покупателем, который не должен
безосновательно отказывать в таком согласовании.
(a) Страхование груза на период транспортировки
Насколько это применимо, 110 процентов от цены
Информационных технологий и прочих Товаров в
свободно конвертируемой валюте, что включает
страхование Товаров от физического повреждения
или ущерба во время транспортировки вплоть до
прибытия на Проектную площадку.
(b)
Страхование Установки “от всех рисков”
Насколько это применимо, 110 процентов от цены
Информационных технологий и прочих Товаров,
что включает страхование Товаров на площадке от
всех рисков физического повреждения или ущерба
(за исключением рисков, которые солидные
страховщики обычно не включают в такого рода
страховые полисы, покрывающие все риски),
которые могут произойти до момента Приемки
Системы в эксплуатацию.
(c)
Страхование в пользу третьей стороны
На условиях, оговоренных в СУК, с покрытием
телесных повреждений или гибели третьих лиц
(включая персонал Покупателя), а также урона или
ущерба
имуществу
(включая
имущество
Покупателя и любые принятые Покупателем
Подсистемы), которые связаны с поставкой и
установкой Информационной системы.
(d)
Страхование ответственности автомобилиста
В соответствии с требованиями действующего
законодательства Страны Покупателя, с покрытием
всех транспортных средств, эксплуатируемых
Поставщиком
или
его
Субподрядчиками
(независимо от того, являются ли они владельцами
таких транспортных средств) в связи с
выполнением Контракта.
(e)
Прочие
виды
страхования,
оговоренные
в
Раздел IV. Общие условия контракта
79
СУК(если таковые имеются).
37.2 Покупатель должен быть указан в качестве
дополнительного страхователя во всех страховых
полисах, оформленных Поставщиком в соответствии со
Статьей 37.1 ОУК, за исключением Страхования в
пользу третьей стороны, а Субподрядчики Поставщика
должны быть указаны в качестве дополнительных
страхователей во всех страховых полисах, оформленных
Поставщиком в соответствии со Статьей 37.1 ОУК, за
исключением
Страхования
груза
на
период
транспортировки. В рамках таких полисов страховщик
отказывается от всех прав суброгации по отношению к
страхователям в том, что касается убытков или исков,
возникающих в связи с выполнением Контракта.
37.3 В качестве доказательства того, что соответствующие
полисы имеют силу и действительны, Поставщик
вручает Покупателю страховые свидетельства (или
копии страховых полисов).
37.4 Поставщик следит за тем, чтобы, по мере возможности,
его Субподрядчики оформляли и сохраняли в силе
необходимые страховые полисы, покрывающие их
сотрудников и транспортные средства, а также работу,
которую они выполняют в рамках Контракта, за
исключением случаев, когда такие Субподрядчики
включены в полисы, оформленные Поставщиком.
37.5 Если Поставщик не оформил и/или не сохранил в силе
страхование, упомянутое в Статьей 37.1 ОУК,
Покупатель может оформить и сохранить в силе любую
из этих страховок и периодически удерживать из любых
сумм, причитающихся Поставщику в рамках Контракта,
любые страховые премии, которые Покупатель
выплатил страховщику, или иным образом возмещать
себе эти выплаты как долг Поставщика.
37.6 Если в Контракте нет иных указаний, Поставщик
готовит и участвует во всех и каждом иске,
предъявленном на основании полисов, оформленных
Поставщиком в соответствии с настоящей Статьей 37, а
все суммы, которые должны быть выплачены
страховщиками,
выплачиваются
Поставщику.
Покупатель оказывает Поставщику любое разумное
содействие, которое может потребоваться Поставщику в
связи с исками по соответствующим страховым полисам.
Что касается страховых исков, затрагивающих интересы
Раздел IV. Общие условия контракта
80
Покупателя, Поставщик не должен отказываться от
каких-либо требований или достигать компромисса со
страховщиком без предварительного письменного
согласия Покупателя. Что касается страховых исков,
затрагивающих интересы Поставщика, Покупатель не
должен отказываться от каких-либо требований или
достигать
компромисса
со
страховщиком
без
предварительного письменного согласия Поставщика.
38. Форс-мажор
38.1 “Форс-мажор” означает любое событие, выходящее за
пределы разумного контроля со стороны Покупателя или
Поставщика (в зависимости от обстоятельств), которое
является неизбежным, несмотря на разумные меры
предосторожности, принимаемые соответствующей
стороной,
и
включает,
без
ограничения
нижеперечисленным, следующее:
(a)
войну, военные действия или военные операции
(будь-то с объявлением или без объявления войны),
вторжение, акт иностранного противника и
гражданскую войну;
(b)
восстание, революцию, мятеж, бунт, узурпацию
гражданской или военной власти, заговор,
массовые волнения, гражданские беспорядки и
террористический акт;
(c)
конфискацию, национализацию, мобилизацию,
принудительное отчуждение или реквизицию по
приказу любого правительства или фактического
органа власти или правителя, или иное действие
или бездействие любого местного, регионального
или национального органа власти;
(d)
забастовку, саботаж, локаут, эмбарго, ограничения
на импорт, перегрузку порта, отсутствие обычных
средств общественного транспорта и связи,
трудовой конфликт, кораблекрушение, нехватку
или
ограничение
подачи
электроэнергии,
эпидемию, карантин и чуму;
(e)
землетрясение,
оползень,
вулканическую
деятельность, пожар, наводнение, прилив, тайфун,
циклон, ураган, шторм, молнию или иное ненастье,
ядерную волну, волну сжатия или иное стихийное
или физическое бедствие;
(f)
случаи, когда Поставщик не смог получить
необходимые
разрешения
на
экспорт
от
Раздел IV. Общие условия контракта
81
правительства (правительств) Страны (Стран)
происхождения Информационных технологий или
прочих Товаров, или Оборудования Поставщика,
при условии, что Поставщик сделал все от него
зависящее,
чтобы
получить
необходимые
разрешения на экспорт, включая тщательное
изучение принципиальной возможности получения
необходимых разрешений на экспорт Системы и
всех ее составных частей.
38.2 Если одна из сторон сталкивается с событием Форсмажор, которое препятствует, мешает или задерживает
выполнение этой стороной каких-либо из ее
обязанностей в рамках Контракта, то она должна
направить второй стороне письменное уведомление о
таком событии и его обстоятельствах в течение
четырнадцати (14) дней после того, как оно произошло.
38.3 Сторона,
направившая
такое
уведомление,
освобождается от выполнения или точного выполнения
своих обязанностей в рамках Контракта на период
действия соответствующего события Форс-мажор и в
том объеме, в каком это событие препятствует, мешает
или задерживает выполнение этой стороной ее
обязанностей.
Срок
Приемки
в
эксплуатацию
продлевается в соответствии со Статьей 40 ОУК
(Перенос Даты приемки в эксплуатацию на более
поздний срок).
38.4 Сторона или стороны, пострадавшие от события Форсмажор, принимают все разумные меры для того, чтобы
уменьшить влияние этого события на исполнение
Контракта и выполнить свои обязанности в рамках
Контракта, не ущемляя при этом права каждой из сторон
на расторжение Контракта в соответствии со Статьей
38.6 ОУК.
38.5 Задержка с выполнением или невыполнение Контракта
любой из сторон вследствие события Форс-мажор:
(a)
не является несоблюдением или нарушением
Контракта;
(b)
(с учетом положений Статей 35.2, 38.3 и 38.4 ОУК)
не дает оснований для предъявления иска о
возмещении убытков или оплате дополнительных
издержек или расходов, обусловленных такой
задержкой с выполнением или невыполнением
Раздел IV. Общие условия контракта
82
Контракта,
если и в том объеме, в каком такая задержка с
выполнением или невыполнение Контракта вызваны
событием Форс-мажор.
38.6 Если одно или несколько событий Форс-мажор,
случившихся в период действия Контракта, существенно
препятствуют, мешают или задерживают выполнение
Контракта в течение периода, превышающего
шестьдесят (60) последовательных дней, или сто
двадцать (120) дней в совокупности, стороны должны
попытаться найти взаимоприемлемое решение, а в
случае неудачи любая из сторон может расторгнуть
Контракт, направив соответствующее уведомление
второй стороне.
38.7 В случае расторжения Контракта на основании Статьи
38.6 ОУК, права и обязанности Покупателя и
Поставщика определяются положениями Статей 41.1.2 и
41.1.3 ОУК.
38.8 Несмотря на положения Статьи 38.5 ОУК, событие
Форс-мажор не распространяется на обязанность
Покупателя произвести платежи Поставщику в рамках
настоящего Контракта.
H. ИЗМЕНЕНИЕ КОМПОНЕНТОВ КОНТРАКТА
39. Изменение
Системы
39.1 Внесение Изменения
39.1.1 С учетом Статей 39.2.5 и 39.2.7 ОУК,
Покупатель имеет право предложить и в
дальнейшем потребовать, чтобы в ходе
выполнения Контракта Директор проекта
периодически поручал Поставщику произвести в
Системе то или иное изменение или
модификацию, внести в нее то или иное
дополнение или исключить из Системы ту или
иную часть (в равной степени именуемые
“Изменение”), при условии, что такое Изменение
не выходит за общие рамки Системы, не
является работой, не имеющей отношения к
Системе,
и
выполнимо
в техническом
отношении как с учетом текущей степени
готовности Системы, так и с учетом технической
Раздел IV. Общие условия контракта
83
совместимости предполагаемого Изменения с
характером
Системы,
первоначально
оговоренной в Контракте.
Изменение может предусматривать, среди
прочего, замену Информационных технологий и
сопутствующих Услуг более современными
версиями, как это предусмотрено в Статье 23
ОУК (Модернизация продукции).
39.1.2 В ходе выполнения Контракта Поставщик может
периодически предлагать Покупателю (с копией
Директору проекта) любые Изменения, которые,
по мнению Поставщика, необходимы или
желательны для улучшения качества или
повышения
эффективности
Системы.
Покупатель, по своему усмотрению, может
утверждать или отклонять любые Изменения,
предложенные Поставщиком.
39.1.3 Несмотря на положения Статей 39.1.1 и 39.1.2
ОУК, ни одно изменение, обусловленное тем,
что Поставщик не выполнил свои обязанности
по Контракту, не считается Изменением и не
дает оснований для корректировки Цены
контракта или Даты приемки в эксплуатацию.
39.1.4 Порядок
оформления
и
осуществления
Изменений указан в Статьях 39.2 и 39.3 ОУК, а
дополнительная информация и образцы форм
приведены в разделе “Образцы форм”
Документации для торгов.
39.1.5 Кроме того, в процессе разработки Плана
проекта Покупатель и Поставщик должны
согласовать
срок,
наступающий
до
запланированной Даты приемки в эксплуатацию,
по истечении которого Технические требования
к Системе “замораживаются”. Любое Изменение,
предложенное после наступления этого срока,
будет рассматриваться после Приемки в
эксплуатацию.
39.2 Изменения, предложенные Покупателем
39.2.1 Если Покупатель предлагает Изменение в
соответствии со Статьей 39.1.1 ОУК, он должен
направить Поставщику “Запрос о подготовке
Раздел IV. Общие условия контракта
84
предложения об Изменении”, в котором
Поставщику предлагается подготовить и
представить
Директору
проекта
(по
возможности,
в
кратчайшие
сроки)
“Предложение об Изменении”, в состав которого
должна войти следующая информация:
(a) краткое описание Изменения;
(b) влияние Изменения на сроки доведения до
стадии Приемки в эксплуатацию;
(c) подробные сметные
Изменения;
расчеты
стоимости
(d) влияние Изменения (если таковое имеется) на
Функциональные гарантии;
(e) влияние Изменения
положения Контракта.
на
любые
иные
39.2.2 До того, как Поставщик подготовит и представит
“Предложение об Изменении”, он должен
направить
Директору
проекта
“Предварительную
смету
Изменения”,
включающую оценку стоимости подготовки
Предложения об Изменении, а также первое
ориентировочное
описание
предлагаемого
подхода к осуществлению Изменения и
стоимости его осуществления. Получив от
Поставщика Предварительную смету Изменения,
Покупатель должен либо:
(a) принять сметные расчеты Поставщика, дав
ему указание приступить к подготовке
Предложения об Изменении; либо
(b) сообщить Поставщику о неприемлемости
какой-либо части этой Предварительной
сметы
Изменения
и
попросить
его
пересмотреть свою оценку; либо
(c) сообщить Поставщику о том, что Покупатель
не намерен осуществлять это Изменение.
39.2.3 Получив от Покупателя указание приступить к
подготовке Предложения об Изменении в
соответствии со Статьей 39.2.2 (a) ОУК,
Поставщик должен оперативно приступить к
подготовке Предложения об Изменении, как это
Раздел IV. Общие условия контракта
85
предусмотрено в Статье 39.2.1 ОУК. Поставщик,
по своему усмотрению, может установить срок
действия Предложения об Изменении, по
истечении которого в случае отсутствия
договоренности
между
Покупателем
и
Поставщиком, предусмотренной в Статье 39.2.6
ОУК, начинает действовать Статья 39.2.7 ОУК.
39.2.4 Насколько это возможно, стоимость любого
Изменения рассчитывается на основании
тарифов и цен, предусмотренных в Контракте.
Если с учетом характера Изменения указанные в
Контракте
тарифы
и
цены
являются
необъективными, стороны Контракта должны
согласовать специальные тарифы для оценки
стоимости Изменения.
39.2.5 Если до начала или в процессе подготовки
Предложения об Изменении выясняется, что
совокупным итогом выполнения Запроса о
подготовке предложения об Изменении, а также
всех прочих Распоряжений об Изменениях,
которые уже приобрели обязательный характер
для Поставщика в соответствии с настоящей
Статьей 39 ОУК, станет увеличение или
уменьшение первоначальной Цены контракта,
указанной в Статье 2 Контрактного соглашения
(Цена контракта), более чем на пятнадцать (15)
процентов,
Поставщик
может
направить
письменное возражение против такого Запроса о
подготовке предложения об Изменении до того,
как представит Предложение об Изменении.
Если Покупатель согласен с возражением
Поставщика, он
должен
отозвать
свое
предложение об Изменении и направить
Поставщику письменное уведомление о своем
согласии.
Если Поставщик не возражает против Запроса о
подготовке предложения об Изменении, то это
никак не ущемляет ни его права на возражение
против любых последующих запросов об
Изменениях или Распоряжений об Изменениях,
ни его права учитывать в случае такого
дальнейшего возражения процент увеличения
или
уменьшения
Цены
контракта,
обусловленный каким-либо Изменением, против
Раздел IV. Общие условия контракта
86
которого Поставщик не возражал ранее.
39.2.6 После получения Предложения об Изменении
Покупатель и Поставщик должны согласовать
вопросы, содержащиеся в Предложении об
Изменении. В течение четырнадцати (14) дней
после достижения такой договоренности
Покупатель, если он намерен осуществить это
Изменение,
должен
выдать
Поставщику
Распоряжение об Изменении. Если Покупатель
не может принять решения в течение
четырнадцати (14) дней, он должен сообщить об
этом Поставщику, дав ему подробную
информацию о том, когда Поставщик сможет
получить решение. Если Покупатель, по какимлибо причинам, решает не осуществлять
Изменения, он должен сообщить об этом
Поставщику в течение тех же четырнадцати (14)
дней. В этом случае Поставщик имеет право
получить компенсацию всех обоснованных
расходов, понесенных им в связи с подготовкой
Предложения об Изменении, при условии, что
эти расходы не превышают суммы, указанной
Поставщиком
в
Предварительной
смете
Изменения, представленной в соответствии со
Статьей 39.2.2 ОУК.
39.2.7 Если Покупатель и Поставщик не могут
договориться о цене Изменения, справедливой
корректировке срока доведения до стадии
Приемки в эксплуатацию или о других вопросах,
поднятых в Предложении об Изменении, то
Изменение не производится. Однако это
положение не ограничивает прав сторон,
предусмотренных
в
Статье
6
ОУК
(Урегулирование споров).
39.3 Изменения, предложенные Поставщиком
39.3.1 Если Поставщик предлагает Изменение в
соответствии со Статьей 39.1.2 ОУК, он должен
направить Директору проекта письменную
“Заявку на подготовку предложения об
Изменении” с указанием оснований для
предлагаемого
Изменения
и
сведений,
перечисленных в Статье 39.2.1 ОУК. После
получения Заявки на подготовку предложения об
Раздел IV. Общие условия контракта
87
Изменении
стороны
должны
выполнить
процедуры, изложенные в Статьях 39.2.6 и 39.2.7
ОУК, за исключением того, что для целей
настоящей
Статьи
39.3.1
ОУК
слова
“Предложение
об
Изменении”
должны
толковаться как “ Заявка на подготовку
предложения об Изменении.” Однако, если
Покупатель решит не осуществлять Изменения
или если Покупатель и Поставщик не смогут
согласовать Изменение в течение срока,
указанного Поставщиком в Заявке на подготовку
предложения об Изменении, то в отсутствие иной
договоренности
между
Покупателем
и
Поставщиком Поставщик не будет иметь права на
компенсацию расходов, понесенных в связи с
составлением Заявки на подготовку предложения
об Изменении.
40. Перенос Даты
приемки в
эксплуатацию
на более
поздний срок
40.1
Дата (даты) Приемки в эксплуатацию, указанная в
Графике реализации, переносится на более поздний
срок, если Поставщик вынужден задержать
выполнение или не может выполнить какую-либо из
своих обязанностей в рамках Контракта в силу одной
из следующих причин:
(a) внесение какого-либо Изменения в Систему,
предусмотренного в Статье 39 ОУК (Изменение
Системы);
(b) возникновение любого события Форс-мажор,
предусмотренного в Статье 38 ОУК (Форсмажор);
(c) невыполнение обязательств Покупателем; или
(d) возникновение любых иных обстоятельств, четко
оговоренных в Контракте.
При этом Дата приемки в эксплуатацию переносится на
такой срок, чтобы он был справедливым и
разумным при любых обстоятельствах и
объективно отражал причины, по которым
Поставщик задерживает выполнение или не
может выполнить свои обязанности.
40.2
Если в Контракте нет четких положений,
предусматривающих иное, Поставщик должен
направить Директору проекта запрос о переносе Даты
Раздел IV. Общие условия контракта
88
приемки в эксплуатацию на более поздний срок
вместе с подробным описанием события или
обстоятельств, являющихся основанием для такого
переноса, по возможности, в кратчайшие сроки после
наступления этого события или обстоятельств. После
получения такого запроса и сопутствующей
информации Покупатель и Поставщик должны как
можно скорее согласовать период продления этого
срока. Если Поставщик не согласен с тем, чтó
Покупатель считает справедливым и разумным
продлением срока, Поставщик
имеет
право
использовать в этом вопросе положения Статьи 6
ОУК, касающиеся урегулирования споров.
41. Расторжение
Контракта
40.3
Поставщик должен всегда принимать все разумные
меры для того, чтобы свести к минимуму любые
задержки в выполнении своих обязанностей в рамках
Контракта.
41.1
Расторжение
Покупателя
Контракта
в
силу
удобства
для
41.1.1 Покупатель может в любое время расторгнуть
Контракт на любом основании, направив
Поставщику
уведомление
о
расторжении
Контракта со ссылкой на настоящую Статью 41.1
ОУК.
41.1.2 Получив уведомление о расторжении Контракта
на основании Статьи 41.1.1 ОУК, Поставщик
должен либо в самое ближайшее время, либо
после наступления срока, указанного в
уведомлении о расторжении Контракта:
(a) прекратить все дальнейшие работы, за
исключением тех, которые Покупатель может
оговорить в уведомлении о расторжении
Контракта исключительно в целях защиты
уже выполненной части Системы, или работ,
необходимых для того, чтобы обеспечить
чистоту и безопасность площадки после
своего ухода;
(b) расторгнуть все договоры субподряда, за
исключением тех, которые должны быть
переданы Покупателю в соответствии со
Статьей 41.1.2 (d) (ii) ОУК;
Раздел IV. Общие условия контракта
89
(c) вывезти с площадки все Оборудование
Поставщика,
отозвать
с
площадки
сотрудников
Поставщика
и
его
Субподрядчиков и удалить с площадки все
обломки, осколки и разного рода мусор;
(d) кроме того, с учетом положения о платеже в
Статье 41.1.3 ОУК, Поставщик должен:
(i) предоставить Покупателю те части
Системы, которые были выполнены
Поставщиком по состоянию на день
расторжения Контракта;
(ii) насколько это возможно с правовой точки
зрения, передать Покупателю все права,
титулы
и
выгоды
Поставщика,
касающиеся Системы или Подсистемы,
по состоянию на день расторжения
Контракта, а также, если этого потребует
Покупатель,
любых
договоров
субподряда между Поставщиком и его
Субподрядчиками;
(iii) предоставить Покупателю все чертежи,
спецификации и прочие документы,
которые
не
носят
характера
собственности и были подготовлены
Поставщиком или его Субподрядчиками в
связи с Системой по состоянию на день
расторжения Контракта.
41.1.3 В случае расторжения Контракта на основании
Статьи 41.1.1 ОУК Покупатель выплатить
Поставщику следующие суммы:
(a) Цену контракта, в установленном порядке
отнесенную на части Системы, выполненные
Поставщиком по состоянию на день
расторжения Контракта;
(b) обоснованные
расходы,
понесенные
Поставщиком в связи с вывозом с площадки
Оборудования Поставщика и отзывом
сотрудников
Поставщика
и
его
Субподрядчиков;
(c) любые суммы, которые Поставщик должен
выплатить своим Субподрядчикам в связи с
Раздел IV. Общие условия контракта
90
расторжением
договоров
субподряда,
включая плату за аннулирование договора;
(d) расходы, понесенные Поставщиком в связи с
обеспечением защиты Системы, а также
чистоты и безопасности площадки после его
ухода, как это предусмотрено в Статье 41.1.2
(a) ОУК; и
(e) расходы, связанные с выполнением всех
прочих
обязанностей,
обязательств
и
требований, которые Поставщик, действуя
без злого умысла, мог взять на себя перед
третьими сторонами в связи с Контрактом и
которые не подпадают под пункты (a)-(d)
Статьи 41.1.3 ОУК.
41.2
Расторжение Контракта в силу невыполнения его
условий Поставщиком
41.2.1 Без ущерба для любых других прав или средств
защиты, которыми он может обладать,
Покупатель имеет право незамедлительно
расторгнуть Контракт в перечисленных далее
обстоятельствах,
направив
Поставщику
уведомление о расторжении Контракта с
объяснением причин такого расторжения и со
ссылкой на настоящую Статью 41.2 ОУК:
(a) если Поставщик становится банкротом или
утрачивает платежеспособность, если суд издал
приказ
о
назначении
управляющего
имуществом Поставщика и проведении
процедуры его банкротства, если он пришел к
компромиссному соглашению со своими
кредиторами, или – в случае когда Поставщик
является корпорацией – если принято решение
или издан приказ о его ликвидации (за
исключением добровольной ликвидации в
целях слияния с другими компаниями или
реструктуризации), если в отношении какойлибо части его предприятия или активов
назначен внешний управляющий, или если
Поставщик сам предпринимает или против
него предпринимается другое аналогичное
действие вследствие его задолженности;
(b) если Поставщик переуступает или передает
Раздел IV. Общие условия контракта
91
третьим лицам сам Контракт или любое право
по Контракту, или долю участия в Контракте в
нарушение положений Статьи 42 ОУК
(Цессия); или
(c) если Поставщик, по мнению Покупателя, был
замешан в коррупции, мошенничестве, сговоре,
принуждении или обструкционизме в процессе
конкуренции за получение Контракта или его
выполнения, включая, без
ограничения
нижеперечисленным,
преднамеренно
искаженное
представление
фактов,
касающихся
обладания
Правами
интеллектуальной
собственности
на
оборудование, программное обеспечение или
материалы,
предоставленные
в
рамках
настоящего Контракта, или получения от
владельца такого оборудования, программного
обеспечения или материалов необходимых
полномочий и/или лицензий на их поставку.
Для целей настоящей Статьи:
(i) «коррупция» означает прямое или косвенное
предложение, передачу, получение или
вымогание любой ценности с целью оказать
ненадлежащее влияние на действия другой
стороны;1
(ii) «мошенничество» означает любое действие или
упущение, включая дезинформацию, которое
умышленно или по неосторожности вводит в
заблуждение
или
пытается
ввести
в
заблуждение сторону2 с целью получения
финансовой или другой выгоды или уклонения
от выполнения обязательства;
(iii) «сговор» означает договоренность между
двумя или более сторонами имеющую
1
Под «другой стороной» понимается должностное лицо, имеющие отношение к процессу закупки или к
исполнению контракта. В данном контексте «должностные лица» включают сотрудников
Всемирного Банка и других организаций, принимающих решения по закупкам, или проверяющих
их.
2
Под «стороной» понимается должностное лицо, понятия «выгода» и «обязательство» применимы к
закупочному процессу или исполнению контракта, а «действие или упущение» направлены на
оказание влияния на закупочный процесс или исполнение контракта.
Раздел IV. Общие условия контракта
92
ненадлежащую цель, включая оказание
влияние на действия другой стороны3;
(iv) принуждение»
означает
нанесение
повреждения или ущерба или угроза
нанесения повреждения или ущерба
напрямую или косвенно другой стороне или
собственности другой стороны с целью
оказания ненадлежащего влияния на
действия другой стороны;4
(v)
«обструкционистская практика» это
(аа)
намеренное
уничтожение,
фальсификация, изменение или сокрытие
подтверждающей
информации
при
проведении расследования или ложное
заявление для того, чтобы фактически
затруднить расследование Банка по
обвинению в коррупции, мошенничестве,
сговоре или насилии и принуждении; и/или
угроза, притеснение или запугивание
любой из сторон, с целью помешать этой
стороне обнародовать известные ей
обстоятельства,
относящиеся
к
расследованию,
или
проводить
расследование; или
(bb)
действия, направленные на то,
чтобы фактически помешать
Банку
воспользоваться своими правами на
проведение
инспекции
и
аудита,
предусмотренных параграфом 3.1 (е),
приведенном далее.
41.2.2 Если Поставщик:
(a) отказался от Контракта или аннулировал его;
(b) без веских оснований не приступил к работе
над Системой в оперативном порядке;
(c) систематически не выполняет Контракт в
соответствии
с
его
условиями
или
систематически пренебрегает исполнением
3
Под «сторонами» понимаются участники закупочного процесса (включая должностные лица),
пытающиеся установить цены предложений на искусственном неконкурентном уровне.
4
Под «сторонами» понимаются участники закупочного процесса или исполнения контракта
Раздел IV. Общие условия контракта
93
своих обязанностей по Контракту без веских
причин;
(d) отказывается или не может предоставить
Материалы, Услуги или рабочую силу в
объеме, достаточном для
создания и
завершения Системы так, как это указано в
Согласованном и уточненном плане проекта,
представленном в соответствии со Статьей 19
ОУК, такими темпами, чтобы Покупатель мог
быть уверен в том, что Поставщик способен
довести Систему до стадии Приемки в
эксплуатацию к наступлению Даты приемки в
эксплуатацию (с учетом ее переноса),
то Покупатель, без ущерба для других прав,
которыми он может обладать по Контракту,
может направить Поставщику уведомление,
описывающее характер нарушения условий
Контракта и требующее, чтобы Поставщик
исправил положение. Если Поставщик не
исправляет положения или не принимает мер
для его исправления в течение четырнадцати
(14) дней после получения такого уведомления,
Покупатель имеет право незамедлительно
расторгнуть Контракт, направив Поставщику
уведомление о таком расторжении со ссылкой на
настоящую Статью 41.2 ОУК.
41.2.3 Получив уведомление о расторжении Контракта
на основании Статей 41.2.1 или 41.2.2 ОУК,
Поставщик должен либо в самое ближайшее
время, либо
после наступления срока,
указанного в уведомлении о расторжении
Контракта:
(a) прекратить все дальнейшие работы, за
исключением тех, которые Покупатель может
оговорить в уведомлении о расторжении
Контракта исключительно в целях защиты
уже выполненной части Системы, или работ,
необходимых для того, чтобы обеспечить
чистоту и безопасность площадки после
своего ухода;
(b) расторгнуть все договоры субподряда, за
исключением тех, которые должны быть
переданы Покупателю в соответствии со
Раздел IV. Общие условия контракта
94
Статьей 41.2.3 (d) ОУК;
(c) предоставить Покупателю те части Системы,
которые были выполнены Поставщиком по
состоянию на день расторжения Контракта;
(d) насколько это возможно с правовой точки
зрения, передать Покупателю все права,
титулы и выгоды Поставщика, касающиеся
Системы или Подсистем, по состоянию на
день расторжения Контракта, а также, если
этого
потребует
Покупатель,
любых
договоров субподряда между Поставщиком и
его Субподрядчиками;
(e) предоставить Покупателю все чертежи,
спецификации
и
прочие
документы,
подготовленные Поставщиком или его
Субподрядчиками в связи с Системой по
состоянию на день расторжения Контракта.
41.2.4 Покупатель может прийти на площадку, удалить
Поставщика и завершить Систему либо
самостоятельно, либо наняв для этого третье
лицо. После завершения Системы или при
наступлении более раннего срока, который
Покупатель считает приемлемым, Покупатель
должен направить Поставщику уведомление о
том, что соответствующее Оборудование
Поставщика будет возвращено Поставщику на
территории или в окрестностях площадки, и
возвратить это Оборудование Поставщику
согласно уведомлению. После этого Поставщик
должен незамедлительно и за свой счет вывезти
или организовать вывоз такого Оборудования с
площадки.
41.2.5 С учетом положений Статьи 41.2.6 ОУК
Поставщик имеет право на получение Цены
контракта, отнесенную на ту часть Системы,
которая была выполнена по состоянию на день
расторжения Контракта, а также расходы (если
таковые имеются), понесенные Поставщиком в
связи с обеспечением защиты Системы, а также
чистоты и безопасности площадки после его
ухода, как это предусмотрено в Статье 41.2.3 (a)
ОУК.
Любые
суммы,
причитающиеся
Раздел IV. Общие условия контракта
95
Покупателю от Поставщика и начисленные до
наступления дня расторжения Контракта,
удерживаются из суммы, которая должна быть
выплачена
Поставщику
по
настоящему
Контракту.
41.2.6 В случае завершения Системы Покупателем
определяется стоимость таких работ по
завершению
Системы.
Если
сумма,
причитающаяся Поставщику в соответствии со
Статьей 41.2.5 ОУК, плюс обоснованные
расходы, понесенные Покупателем в связи с
завершением Системы, превышают Цену
контракта, ответственность за это превышение
возлагается
на
Поставщика.
Если
это
превышение больше суммы, причитающейся
Поставщику в соответствии со Статьей 41.2.5
ОУК,
Поставщик
выплачивает
разницу
Покупателю, а если это превышение меньше
суммы,
причитающейся
Поставщику
в
соответствии со Статьей 41.2.5 ОУК, Покупатель
выплачивает разницу Поставщику. Покупатель и
Поставщик должны письменно согласовать
описанные выше вычисления, а также порядок
уплаты любой из таких сумм.
41.3
Расторжение Контракта Поставщиком
41.3.1 Если:
(a) Покупатель в установленные сроки не
выплатил Поставщику какую-либо сумму,
причитающуюся ему по Контракту, не
утвердил
какой-либо
счет-фактуру или
сопутствующую документацию, не имея для
этого веских оснований, предусмотренных в
СУК, или серьезно нарушил Контракт, то
Поставщик может направить Покупателю
уведомление с требованием выплаты этой
суммы, а также процентов, начисленных на нее
в соответствии со Статьей 12.3 ОУК, с
требованием утверждения этого счета-фактуры
или сопутствующей документации, или с
указанием характера нарушения и требованием
о том, чтобы Покупатель исправил положение
(в зависимости от обстоятельств). Если
Покупатель не выплачивает эту сумму вместе
Раздел IV. Общие условия контракта
96
начисленными на нее процентами, не
утверждает
этот
счет-фактуру
или
сопутствующую документацию, или не
объясняет причин отказа в таком утверждении,
не исправляет своего нарушения или не
принимает мер для его исправления в течение
четырнадцати (14) дней после получения
уведомления Поставщика; или
(b) Поставщик не может выполнить какую-либо из
своих обязанностей в рамках Контракта по
вине Покупателя, включая, без ограничения
нижеперечисленным, тот факт, что Покупатель
не смог обеспечить владение площадкой или
иной территорией или доступа к ним, или
невозможность получения от государства
какого-либо разрешения, необходимого для
выполнения и/или завершения Системы;
то Поставщик может направить Покупателю
уведомление об этих фактах, и, если Покупатель
не выплатил оставшуюся сумму, не утвердил счетфактуру или сопутствующую документацию, не
объяснил причины отказа в таком утверждении
или не устранил нарушение в течение двадцати
восьми (28) дней после получения такого
уведомления, или, если Поставщик по-прежнему
не может выполнять какую-либо из своих
обязанностей в рамках Контракта по вине
Покупателя по истечении двадцати восьми (28)
дней после направления указанного уведомления,
Поставщик
имеет
право
незамедлительно
расторгнуть Контракт, направив Покупателю
соответствующее уведомление со ссылкой на
настоящую Статью 41.3.1 ОУК.
41.3.2 Поставщик может незамедлительно расторгнуть
Контракт,
направив
Покупателю
соответствующее уведомление со ссылкой на
настоящую Статью 41.3.2 ОУК, если Покупатель
становится
банкротом
или
утрачивает
платежеспособность, если суд издал приказ о
назначении
управляющего
имуществом
Покупателя и проведении процедуры его
банкротства, если он пришел к компромиссному
соглашению со своими кредиторами, или – в
случае когда Покупатель является корпорацией –
Раздел IV. Общие условия контракта
97
если принято решение или издан приказ о его
ликвидации (за исключением добровольной
ликвидации в целях слияния с другими
компаниями или реструктуризации), если в
отношении какой-либо части его предприятия
или активов назначен внешний управляющий,
или если Покупатель сам предпринимает или
против
него
предпринимается
другое
аналогичное
действие
вследствие
его
задолженности;
41.3.3 В случае расторжения Контракта на основании
Статей 41.3.1 или 41.3.2 ОУК, Поставщик
должен незамедлительно:
(a) прекратить все дальнейшие работы, за
исключением
тех,
которые
могут
потребоваться для защиты уже выполненной
части Системы, или работ, необходимых для
того, чтобы обеспечить чистоту и безопасность
площадки после своего ухода;
(b) расторгнуть все договоры субподряда, за
исключением тех, которые должны быть
переданы Покупателю в соответствии со
Статьей 41.3.3 (d) (ii) ОУК;
(c) вывезти с площадки все Оборудование
Поставщика
и
отозвать
с
площадки
сотрудников
Поставщика
и
его
Субподрядчиков.
(d) Кроме того, с учетом положения о платеже в
Статье 41.3.4 ОУК, Поставщик должен:
(i) предоставить
Покупателю
те
части
Системы, которые были выполнены
Поставщиком по состоянию на день
расторжения Контракта;
(ii) насколько это возможно с правовой точки
зрения, передать Покупателю все права,
титулы и выгоды Поставщика, касающиеся
Системы или Подсистем, по состоянию на
день расторжения Контракта, а также, если
этого потребует Покупатель, любых
договоров субподряда между Поставщиком
Раздел IV. Общие условия контракта
98
и его Субподрядчиками;
(iii) насколько это возможно с правовой точки
зрения, предоставить Покупателю все
чертежи,
спецификации
и
прочие
документы, подготовленные Поставщиком
или его Субподрядчиками в связи с
Системой
по
состоянию
на
день
расторжения Контракта.
41.3.4 В случае расторжения Контракта на основании
Статей 41.3.1 или 41.3.2 ОУК Покупатель
должен произвести Поставщику все платежи,
указанные в Статье 41.1.3 ОУК, и выплатить ему
обоснованную компенсацию всех убытков, за
исключением упущенной прибыли, или ущерба,
понесенного Поставщиком в результате или в
связи, или вследствие расторжения Контракта.
41.3.5 Расторжение Контракта Поставщиком на
основании настоящей Статьи 41.3 ОУК не
ущемляет никаких других прав или средств
защиты Поставщика, которыми он может
пользоваться в связи с осуществлением или в
дополнение к осуществлению прав, полученных
на основании Статьи 41.3 ОУК.
42. Цессия
41.4
В настоящей Статье 41 ОУК выражение
“выполненная часть Системы” включает все
выполненные
Поставщиком
работы,
предоставленные им Услуги, а также все
Информационные технологии или прочие Товары,
которые Поставщик приобрел (или обязан купить в
соответствии
с
имеющимся
юридическим
обязательством) и которые были использованы или
предназначены для использования для нужд Системы
вплоть до наступления дня расторжения Контракта,
включительно.
41.5
В настоящей Статье 41 ОУК при расчете любых сумм,
причитающихся Поставщику от Покупателя, следует
учитывать
все
суммы,
ранее
выплаченные
Покупателем Поставщику в рамках Контракта,
включая любые авансовые платежи, произведенные в
соответствии с положениями СУК.
42.l
Без предварительного согласия второй стороны,
Раздел IV. Общие условия контракта
99
ни Покупатель, ни Поставщик не должны
переуступать третьим лицам ни Контракт, ни его
часть, ни какие-либо права, выгоды или
обязанности в рамках Контракта, ни доли
участия в Контракте, за исключением того, что
Поставщик может переуступать (полностью или
в виде залога) любые суммы, которые ему
причитаются или могут причитаться в будущем,
в рамках Контракта.
Раздел V. Специальные условия контракта
100
РАЗДЕЛ V. СПЕЦИАЛЬНЫЕ УСЛОВИЯ КОНТРАКТА (СУК)
Перечень статей
A. Контракт и его толкование ........................................................................................102
1.
2.
3.
4.
5.
6.
Определения (Статья ОУК 1) ..................................................................................102
Контрактная документация (Статья ОУК 2) ..........................................................102
Толкование (Статья ОУК 3) .....................................................................................102
Уведомления (Статья ОУК 4) ..................................................................................103
Регулирующее право (Статья ОУК 5).....................................................................103
Урегулирование споров (Статья ОУК 6) ................................................................103
B. Предмет Контракта......................................................................................................104
7. Состав Системы (Статья ОУК 7) .............................................................................104
8. Сроки начала работ и Приемки Системы в эксплуатацию (Статья ОУК 8) .......104
9. Обязанности Поставщика (Статья ОУК 9) .............................................................104
10. Обязанности Покупателя (Статья ОУК 10) ..........................................................104
C. Платеж............................................................................................................................105
11. Цена контракта (Статья ОУК 11) ..........................................................................105
12. Условия платежа (Статья ОУК 12) .......................................................................105
13. Обеспечение (Статья ОУК 13)...............................................................................106
14. Налоги и пошлины (Статья ОУК 14) .....................................................................106
D. Интеллектуальная собственность ............................................................................107
15. Авторские права (Статья ОУК 15) ........................................................................107
16. Лицензии на Программные продукты (Статья ОУК 16) .....................................107
17. Конфиденциальная информация (Статья ОУК 17) .............................................108
E. Поставка, установка, проведение испытаний, ввод в эксплуатацию и приемка
Системы ...............................................................................................................................108
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
Представители (Статья ОУК 18) ...........................................................................108
План проекта (Статья ОУК 19) ..............................................................................109
Заключение договоров субподряда (Статья ОУК 20) .........................................110
Проектно-конструкторская документация (Статья ОУК 21) .............................110
Закупка, поставка и транспортировка (Статья ОУК 22) .....................................111
Модернизация продукции (Статья ОУК 23) .......... Error! Bookmark not defined.
Реализация, установка и прочие услуги (Статья ОУК 24) ..................................111
Инспекция и тестирование (Статья ОУК 25) .......................................................111
Установка Системы (Статья ОУК 26) ...................................................................111
Ввод и Приемка в эксплуатацию (Статья ОУК 27) .............................................111
F. Гарантии и ответственность ......................................................................................112
28. Гарантия соблюдения сроков Приемки в эксплуатацию (Статья ОУК 28) ......112
29. Ответственность за дефекты (Статья ОУК 29) ....................................................112
Раздел V. Специальные условия контракта
101
30. Функциональные гарантии (Статья ОУК 30) .......................................................112
31. Гарантия соблюдения Прав интеллектуальной собственности (Статья ОУК 31)113
32. Возмещение ущерба от нарушения Прав интеллектуальной собственности
(Статья ОУК 32) ....................................................................................................113
33. Пределы ответственности (Статья ОУК 33) ........................................................113
G. Распределение рисков .................................................................................................113
34. Передача прав собственности (Статья ОУК 34) ..................................................113
35. Уход за Системой (Статья ОУК 35) ......................................................................113
36. Утрата или повреждение имущества; несчастный случай или травма на
производстве; возмещение ущерба (Статья ОУК 36) .......................................113
37. Страхование (Статья ОУК 37) ...............................................................................113
38. Форс-мажор (Статья ОУК 38)................................................................................114
H. Изменение компонентов Контракта ........................................................................114
39. Изменение Системы (Статья ОУК 39) ..................................................................114
40. Перенос Даты приемки в эксплуатацию на более поздний срок (Статья ОУК
40) ...........................................................................................................................114
41. Расторжение Контракта (Статья ОУК 41) ............................................................114
42. Цессия (Статья ОУК 42) .........................................................................................114
Раздел V. Специальные условия контракта
102
Специальные условия контракта
Изложенные далее Специальные условия контракта (СУК) дополняют или
модифицируют Общие условия контракта (ОУК). В случае противоречий положения
СУК имеют преимущественную силу перед положениями Общих условий контракта.
Для ясности все номера статей ОУК, на которые даются ссылки, приведены в левой
колонке СУК.
A. КОНТРАКТ И ЕГО ТОЛКОВАНИЕ
1. Определения (Статья ОУК 1)
ОУК 1.1 (a) (ix)
Применяется издание Руководства по закупкам, датированное
Маем 2004 года, с изменениями от октября 2006 года и мая 2010 года
ОУК 1.1 (b) (i)
Наименование Покупателя: Министерство здравоохранения и
социального развития Республики Казахстан.
Директор проекта: Цой Алексей Владимирович–Вице-министр
здравоохранения и социального развития Республики
Казахстан
Страна Покупателя: Республика Казахстан.
ОУК 1.1 (b) (ii)
ОУК 1.1 (e) (i)
ОУК 1.1 (e) (iii)
ОУК 1.1 (e) (x)
ОУК 1.1. (e)
(xii)
Проектная площадка (площадки): как установлено в Перечне
площадок Системы, приведенном в разделе “Технические
требования”.
Контракт остается в силе до тех пор, пока не будет выполнена
Информационная система и предоставлены все Услуги, за
исключением случаев более раннего расторжения Контракта в
соответствии с его положениями.
Период послегарантийного обслуживания составляет 0, начиная с
окончания Гарантийного периода.
2. Контрактная документация (Статья ОУК 2)
ОУК 2
Для Статьи ОУК 2 нет никаких Специальных условий контракта.
3. Толкование (Статья ОУК 3)
ОУК 3.1.1
Языком, который управляет Контрактом, является:
язык.
английский
В случае присуждения контракта компании страны Покупателя, по
желанию участника торгов Покупатель может заключить контракт
на русском языке. В этом случае, Покупатель должен предоставить
Раздел V. Специальные условия контракта
103
перевод контракта на английском языке в Банк
4. Уведомления (Статья ОУК 4)
ОУК 4.3
Адрес Директора Проекта:
010000, Республика Казахстан, г. Астана, ул. Орынбор, 8,
5-6 подъезды, каб. 1128,
тел. + 7 (7172) 742906, факс: + 7 (7172) 743608, e-mail
sh.zhumabaeva@mzsr.gov.kz
Резервный адрес Покупателя:
010000, г. Астана, Республика Казахстан, ул. Иманова 19, офис 504,
Телефон: + 7172 787 235, Факс: + 7172 787 247,
e-mail. kazhealth.procurement@gmail.com
5. Регулирующее право (Статья ОУК 5)
ОУК 5.1
Контракт интерпретируется в соответствии с законодательством
Республики Казахстан.
6. Урегулирование споров (Статья ОУК 6)
ОУК 6.1.4
Международный коммерческий арбитражный суд при Европейской
арбитражной палате, Бельгия, 1050, Брюссель, Авеню Луиз 146
Тел.\Факс +38 044-581-30-77 / 55
secretary@chea-taic.be
ОУК 6.2.3
Правила процедур судебных разбирательств:
(a) если Поставщик является иностранным подданным (включая
совместное предприятие когда, по крайней мере, один из партнеров
иностранец): любые разногласия, споры и иски, выходящие из
контракта или имеющие отношения к данному контракту, или
нарушения, прекращение или недействительность контракта будут
решены путем судебного разбирательства согласно UNCITRAL
ArbitrationRules которые в настоящее время в силе. Место
разбирательства не должно быть страной Покупателя или
Поставщика;
(b) если Поставщик является гражданином страны Покупателя:
любое разногласие между Покупателем и Поставщиком, который
является гражданином страны Покупателя, происходящее из
настоящего контракта будет отнесено к судебным разбирательствам
Раздел V. Специальные условия контракта
104
согласно законам страны Покупателя.
B. ПРЕДМЕТ КОНТРАКТА
7. Состав Системы (Статья ОУК 7)
ОУК 7.3
Текущих расходов для настоящего контракта нет.
В то же время Поставщик должен перед заключением контракта
предоставить гарантийное письмо о том, что в случае
необходимости Покупатель может привлечь Поставщика для
оказания услуг в постгарантийный период по ставкам, указанным в
конкурсном предложении.
8. Сроки начала работ и Приемки Системы в эксплуатацию (Статья ОУК 8)
ОУК 8.1
ОУК 8.2
Поставщик должен приступить к работе над Системой в течение:
15 дней после наступления Даты вступления Контракта в силу.
Приемка Системы в эксплуатацию должна быть произведена в
соответствии с Графиком реализации, приведенному в разделе
“Технические требования”.
9. Обязанности Поставщика (Статья ОУК 9)
ОУК 9.9
К числу дополнительных обязанностей Поставщика относятся:
Закуп и обеспечение лицензии для систем управления базами
данных используемых в предложенном решении.
Закуп и обеспечение лицензии для всех сторонних
информационных систем и приложений.
Обеспечение гарантии и технической поддержки на 3 года.
Если для каких-либо частей требуется годовая лицензия,
стоимость этих лицензий на первые 3 года должна быть
запланирована в расходах технической поддержки.
Обучение персонала Покупателя использованию и настройке
всех компонентов, приложений, сервисов решения.
10. Обязанности Покупателя (Статья ОУК 10)
ОУК 10.12
К числу дополнительных обязанностей Покупателя относятся: нет.
Раздел V. Специальные условия контракта
105
C. ПЛАТЕЖ
11. Цена контракта (Статья ОУК 11)
ОУК 11.2 (b)
Корректировка Цены контракта производится следующим образом:
не производится.
12. Условия платежа (Статья ОУК 12)
ОУК 12.1
С учетом положений Статьи 12 ОУК (Условия платежа)
Покупатель выплачивает Цену контракта согласно категориям и в
порядке, как описано ниже. Только категории Авансовый платеж и
Интеграция всей Системы относятся ко всей цене Контракта. В
остальных платежных категориях понятие «полная цена
Контракта» означает общую стоимость товаров или услуг по
конкретной платежной категории как определено в форме Ценовых
таблиц. Внутри каждой такой категории График реализации
Контракта приводить к пропорциональным частичным платежам
полной цены контракта по данной категории, которая
соответствует товарам и услугам, фактически Доставленным,
Установленным или Принятым в эксплуатацию на основании тех
расценок и в тех валютах, которые указаны в Таблицах цен,
приведенных в Контрактном соглашении.
(a)
Авансовый платеж
десять процентов (10%) от полной Цены контракта
выплачивается по получении требования, к которому
прилагается Залоговое обеспечение авансового платежа,
указанное в Статье 13.2 ОУК.
(b)
Информационные технологии, Материалы и прочие Товары,
в том числе Кастомизированных программных продуктов и
Кастомизированных материалов:
сорок процентов (40%) от пропорциональной
контракта для этой категории после Доставки
Цены
тридцать процентов (30%) от той же цены после установки;
(с)
Услуги:
Семьдесят процентов (70%) от пропорциональной Цены
контракта за предоставленные услуги выплачиваются после
установки Системы.Перечень услуг приведен в в пункте R12
Раздела V «Технических требований» для лотов № 1-9 и R13
Раздел V. Специальные условия контракта
106
Раздела V «Технических требований» для лота № 10.
(d)
Интеграция всей Системы
Двадцать процентов (20%) от полной Цены контракта
выплачиваются как заключительный платеж после Приемки
в эксплуатацию Системы как единой, интегрированной
системы.
ОУК 12.3
ОУК 12.4
Покупатель выплатит Поставщику проценты за просроченные
выплаты в размере: 0,01 % от просроченной суммы за каждый день
просрочки
Что касается местных товаров и Услуг, Поставщик выставляет
Покупателю счет в валюте Контрактного соглашения и Таблицах
цен, на которые даются ссылки.
13. Обеспечение (Статья ОУК 13)
ОУК 13.2.1
ОУК 13.2.2
В течение двадцати восьми (28) дней со дня подписания контракта
Поставщик должен предоставить Залоговое обеспечение
авансового платежа на ту же сумму и в той же валюте, что и
Авансовый платеж, описанный выше в СУК для Статьи 12.1 ОУК.
Уменьшение суммы Залогового обеспечения Авансового платежа
рассчитываются следующим образом:
“P*a/(100-a), где “P” – сумма всех платежей, произведенных
Поставщику к настоящему времени (за исключением Авансового
платежа), а “a” – Авансовый платеж, представленный в виде
процента от Цены контракта в соответствии с положением
СУК для Статьи 12.1 ОУК.
ОУК 13.3.1
ОУК 13.3.4
Залоговое обеспечение выполнения Контракта выражается в
валюте Контракта, а его сумма составляет 10 (десять) процентов от
Цены контракта.
В течение Гарантийного периода (т.е. после Приемки Системы в
эксплуатацию) Залоговое обеспечение выполнения Контракта
уменьшается до 5 процентов от Цены контракта.
14. Налоги и пошлины (Статья ОУК 14)
ОУК 14
Для Статьи 14 ОУК нет никаких Специальных условий контракта.
Раздел V. Специальные условия контракта
107
D. ИНТЕЛЛЕКТУАЛЬНАЯ СОБСТВЕННОСТЬ
15. Авторские права (Статья ОУК 15)
ОУК 15.3
Покупатель имеет право переуступить, передать по лицензии или
иным образом добровольно передать свои контрактные права на
использование Стандартных программных продуктов или их
компонентов без предварительного письменного согласия
Поставщика в следующих случаях:
для структурных подразделений Покупателя (областных, городских
и районных объектов здравоохранения) и для всех наследников в
случае каких-либо реорганизаций Покупателя в соответствии с
законодательными актами страны Покупателя.
Права и обязанности Покупателя и Поставщика в отношении
Кастомизированных материалов или их компонентов, заключаются
в следующем: не применимо.
ОУК 15.4
ОУК 15.5
“Для выполнения Контракта не нужно никакого “эскроусоглашения” относительно Программных продуктов.
16. Лицензии на Программные продукты (Статья ОУК 16)
ОУК 16.1 (a)
(iii)
ОУК 16.1 (a)
(iv)
Лицензия на Стандартные программные продукты должна быть
действительна: на всей территории Страны Покупателя
На пользование программным обеспечением распространяются
следующие дополнительные ограничения: нет
ОУК 16.1 (b) (ii) Лицензия на Программные продукты (За исключением Системных
программных продуктов) должна предусматривать возможность их
копирования для использования на замещающем компьютере
(сервере) или переноса на замещающий компьютер (сервер): при
условии, что замещающий компьютер(сервер) относится
приблизительно к тому же классу компьютеров (серверов) и
допускает приблизительно такое же число пользователей, если это
многопользовательский компьютер (сервер)
ОУК 16.1 (b)
Лицензия на Программные продукты должна предусматривать
(vi)
возможность раскрытия информации о Программных продуктах
поставщикам вспомогательных услуг или их субподрядчикам
(исключительно в целях выполнения такими поставщиками или их
субподрядчиками соответствующих контрактов на оказание
вспомогательных услуг),а также возможность воспроизведения
Программных продуктов для использования указанными лицами (в
том числе на основании действующей сублицензии) при условии
соблюдения ограничений, изложенных в настоящем Контракте.
Раздел V. Специальные условия контракта
ОУК 16.1 (b)
(vii)
ОУК 16.2
108
Помимо лиц, перечисленных в Статье 16.1 (b) (vi) ОУК,
информация о Программных продуктах может быть раскрыта для
лиц занимающихся разработкой ЕИСЗ и воспроизведена для
использования этими лицами, при условии соблюдения
ограничений, изложенных в настоящем Контракте.
Поставщик имеет право проводить аудит Стандартных
программных продуктов на следующих условиях:
если Покупатель согласен с проведением аудита на месте, он может
оговорить его условия, включая следующее: продолжительность и
число таких аудиторских проверок в течение года, возможные часы
или дни для их проведения, категории проверяемого программного
обеспечения, порядок доступа к оборудованию или программному
обеспечению Покупателя, количество и организационная
принадлежность отдельных аудиторов, сроки и условия
направления
заблаговременных
уведомлений,
возмещение
Поставщиком убытков, обязательств и расходов Покупателя,
являющихся прямым следствием аудита и т.д.
17. Конфиденциальная информация (Статья ОУК 17)
ОУК 17.1
ОУК 17.7
Условия соблюдения конфиденциальности, изложенные в Статье
17.1 ОУК, остаются без изменений.
Положения настоящей Статьи 17 ОУК остаются в силе после
окончания срока действия (по любой причине) этого Контракта в
течение “периода, установленного в ОУК.
E. ПОСТАВКА, УСТАНОВКА, ПРОВЕДЕНИЕ ИСПЫТАНИЙ, ВВОД В
ЭКСПЛУАТАЦИЮ И ПРИЕМКА СИСТЕМЫ
18. Представители (Статья ОУК 18)
ОУК 18.1
Для Директора проекта Покупателя установлены следующие
дополнительные полномочия и/или ограничения как для
представителя Покупателя в вопросах, касающихся Контракта
“никаких дополнительных полномочий или ограничений нет.”.
ОУК 18.2.2
Для Представителя Поставщика установлены следующие
дополнительные полномочия и/или ограничения как для
представителя Поставщика в вопросах, касающихся Контракта:
“никаких дополнительных полномочий или ограничений нет.”.
Раздел V. Специальные условия контракта
109
19. План проекта (Статья ОУК 19)
ОУК 19.1
Разделы Плана проекта должны охватывать следующую тематику:
(а) План организации менеджмента проекта, в котором будет
описаны роли и ответственность персонала Поставщика, с
указанием имен и количество времени работы (человеко-месяцы), а
также описаны какие действия менеджмента и персонала
медицинской организации необходимы для успешного выполнения
проекта
(б) План внедрения систем (ы) в медицинской(их) организации(ях),
который бы доказал, что все требования покупателя для
поставляемых систем выполнены, и это подтверждено
организацией бенефициарием, и что системы сертифицированы в
соответствии с требованиями покупателя
(в) Методология и План разработки / конфигурации, тестирования,
установки, опытной эксплуатации и сертификации поставляемых
систем
(г) Методология и план обучения пользователей с указанием
методов и программы обучения, количества часов, места
предоставления тренингов и передачи технологий как для
пользователей, так и для менеджеров предприятия.
(д) План миграции данных (если существуют такие данные)
(е) План реакции при гарантийном обслуживании и предоставлении
профессиональных услуг при пилотировании: какова время ответа
на устранения ошибок и запросов, указать где будет находиться
персонал поставщика, сколько человек будут задействованы и по
какому графику.
(ж) Методология и план технической поддержки всего
поставляемого ПО и компонент, как во время внедрения, так и
при опытной эксплуатации
ОУК 19.2
В течение тридцати (30) дней после Даты вступления Контракта в
силу Поставщик должен представить Покупателю План проекта. В
течение четырнадцати (14) дней после получения Плана проекта
Покупатель должен сообщить Поставщику о том, чего, по его
мнению, не хватает в Плане проекта для того, чтобы на основании
этого Плана можно было с уверенностью сказать, что предлагаемая
программа работ, предлагаемые методы и/или предлагаемые
Информационные технологии будут отвечать положениям
Технических требований и/или СУК (далее в настоящей Статье 19.2
это именуется “несоответствия”). В течение семи, (7) дней после
получения такого уведомления Поставщик должен скорректировать
План проекта и еще раз представить его Покупателю. В течение
семи (7) дней после повторного представления Плана проекта
Покупатель должен сообщить Поставщику о любых оставшихся
несоответствиях. Эта процедура повторяется до тех пор, пока в
Плане проекта не останется никаких несоответствий. Когда в Плане
Раздел V. Специальные условия контракта
110
проекта не останется никаких несоответствий, Покупатель должен
будет подтвердить это Поставщику в письменном виде. Такой
утвержденный План проекта (“Согласованный и уточненный план
проекта”) носит характер контрактного обязательства и для
Покупателя, и для Поставщика.
ОУК 19.5
Поставщик представляет Покупателю следующие отчеты:
ежеквартальные отчеты о ходе работ, обобщающие:
(a) ежеквартальные отчеты о ходе работ, обобщающие:
(i)
результаты, достигнутые в течение предшествующего
периода времени;
(ii)
(нарастающим итогом на данный момент) отклонения от
графика выполнения этапов, указанных в Согласованном и
уточненном плане проекта;
(iii) корректирующие меры, которые необходимо принять, чтобы
вернуться к запланированному графику выполнения работ;
предлагаемые поправки к запланированному графику;
(iv)
прочие вопросы и нерешенные проблемы; предлагаемые
меры;
(v)
ресурсы, которые, как предполагает Поставщик, должны
быть предоставлены Покупателем в течение следующего отчетного
периода, и/или меры, которые, по мнению Поставщика, должны
быть приняты Покупателем в течение следующего отчетного
периода;
(vi)
прочие вопросы или потенциальные проблемы, которые, как
предполагает Поставщик, могут повлиять на ход и/или
эффективность реализации проекта.
(b) отчеты о проведенных тренингах и результаты (оценки)
(c) месячные журналы с регистрацией запросов о результатах
решения проблем
(d) Отчет о результатах тестирования и сертификации
20. Заключение договоров субподряда (Статья ОУК 20)
ОУК 20
Для Статьи 20 ОУК нет никаких Специальных условий контракта.
21. Проектно-конструкторская документация (Статья ОУК 21)
ОУК 21.2
Контракт выполняется в соответствии с редакцией или
пересмотренной версией всех упомянутых норм и стандартов,
которая была действительна по состоянию на день, наступивший за
60 дней до истечения срока подачи конкурсных предложений.
Раздел V. Специальные условия контракта
111
ОУК 21.3.1
Поставщик
готовит
и
представляет
Директору проекта
перечисленные далее документы, которые Директор проекта должен
утвердить до того, как Поставщик сможет приступить к работе над
Системой или любой Подсистемой, описанной в этих документах:
Нет
a)
22. Закупка, поставка и транспортировка (Статья ОУК 22)
ОУК 22.4.3
ОУК 22.5
Поставщик
будет освобожден от обязательного пользования
транспортной организацией, зарегистрированной в правомочной
стране и должен оформить страховку в одной из правомочных
стран.
Поставщик должен предоставить Покупателю, документы,
указанные в ОУК а также следующие документы: Акт оценки
количества оборудования, подписанный сторонами контракта .
24. Реализация, установка и прочие услуги (Статья ОУК 24)
ОУК 24
Для Статьи 24 ОУК нет никаких Специальных условий контракта.
25. Инспекция и тестирование (Статья ОУК 25)
ОУК 25
Для Статьи 25 ОУК нет никаких Специальных условий контракта.
26. Установка Системы (Статья ОУК 26)
ОУК 26
Необходимые и приемлемые положения:
Нет.
27. Ввод и Приемка в эксплуатацию (Статья ОУК 27)
ОУК 27.2.1
ОУК 27.2.2
Приемочные испытания проводятся следующим образом:
Предэксплуатационные испытания Системы или ее Подсистем по
площадкам проводятся в соответствии с разделом Технических
требований:R14 – для Лотов №1-9 и R15 – для Лота №10.
Если Приемочные испытания Системы или Подсистемы
(Подсистем) не могут успешно завершиться в течение девяноста
(90)дней со дня Установки или в течение любого иного периода,
согласованного Покупателем и Поставщиком, то в этом случае
Раздел V. Специальные условия контракта
112
применяются положения Статьи 27.3.5 (a) или (b) ОУК, в
зависимости от обстоятельств.
F. ГАРАНТИИ И ОТВЕТСТВЕННОСТЬ
28. Гарантия соблюдения сроков Приемки в эксплуатацию (Статья ОУК 28)
ОУК 28.2
ОУК 28.3
Неустойка оценивается по ставке 1 процент за каждую неделю.
Максимальный размер неустойки составляет 10 процентов от Цены
контракта или соответствующей части Цены контракта, как
определено в Таблице Цен, если неустойка относится к одному из
мероприятий/компонентов.
Сроки
доставки
и
установки
оборудования указаны в Разделе VI «Технические требования»,
таблице «График реализации».
Неустойка взимается только в связи с этапом Приемки в
эксплуатацию на основании положений, указанных в Разделе VI,
Глава D.
29. Ответственность за дефекты (Статья ОУК 29)
ОУК 29.1
ОУК 29.3 (iii)
ОУК 29.4
ОУК 29.10
Что касается Программных продуктов, на гарантийные обязанности
Поставщика распространяются следующие исключения или
ограничения: Нет
Поставщик гарантирует, что перечисленные далее позиции
находились на рынке в течение указанных ниже минимально
приемлемых периодов времени: Для данного Контракта нет
никаких особых требований по минимально приемлемым срокам,
за исключением того, что эти Информационные технологии
должны были выпускаться на рынок ранее.
Гарантийный период (N) начинается в день Приемки в
эксплуатацию Системы (или Подсистемы) и продолжается в
течение: 3 лет в соответствии с R12.4. и R13.4 соответственно
В течение Гарантийного периода Поставщик должен начать
необходимую работу по исправлению дефекта или устранению
ущерба не позднее 15 рабочих дней после получения уведомления.
30. Функциональные гарантии (Статья ОУК 30)
ОУК 30
Для Статьи 30 ОУК нет никаких Специальных условий контракта.
Раздел V. Специальные условия контракта
113
31. Гарантия соблюдения Прав интеллектуальной собственности (Статья ОУК
31)
ОУК 31
Для Статьи 31 ОУК нет никаких Специальных условий контракта.
32. Возмещение ущерба от нарушения Прав интеллектуальной собственности
(Статья ОУК 32)
ОУК 32
Для Статьи 32 ОУК нет никаких Специальных условий контракта.
33. Пределы ответственности (Статья ОУК 33)
ОУК 33
Для Статьи 33 ОУК нет никаких Специальных условий контракта.
G. РАСПРЕДЕЛЕНИЕ РИСКОВ
34. Передача прав собственности (Статья ОУК 34)
ОУК 34
Для Статьи 34 ОУК нет никаких Специальных условий контракта.
35. Уход за Системой (Статья ОУК 35)
ОУК 35
Для Статьи 35 ОУК нет никаких Специальных условий контракта.
36. Утрата или повреждение имущества; несчастный случай или травма на
производстве; возмещение ущерба (Статья ОУК 36)
ОУК 36
Для Статьи 36 ОУК нет никаких Специальных условий контракта
37. Страхование (Статья ОУК 37)
ОУК 37.1 (c)
ОУК 37.1 (e)
Поставщик оформляет Страхование в пользу третьей стороны на
сумму 150 000 долларов США с вычетом из любых страховых
выплат в размере не более 10 000 долларов США. Застрахованными
сторонами являются сотрудники Министерства здравоохранения и
социального развития Республики Казахстан, местных объектов
здравоохранения
МЗСР
РК,
Центр
информатизации
здравоохранения,
субподрядчиков
из
вышеперечисленных
организаций, и все стороны, консультантов и поставщиков.
Страхование действительно с даты вступления контракта в силу до
его завершения.
Для Статьи 37.1 (е) ОУК нет никаких Специальных условий
контракта.
Раздел V. Специальные условия контракта
114
38. Форс-мажор (Статья ОУК 38)
ОУК 38
Для Статьи 38 ОУК нет никаких Специальных условий контракта.
H. ИЗМЕНЕНИЕ КОМПОНЕНТОВ КОНТРАКТА
39. Изменение Системы (Статья ОУК 39)
ОУК 39
Для Статьи 39 ОУК нет никаких Специальных условий контракта.
40. Перенос Даты приемки в эксплуатацию на более поздний срок (Статья ОУК
40)
ОУК 40
Для Статьи 40 ОУК нет никаких Специальных условий контракта.
41. Расторжение Контракта (Статья ОУК 41)
ОУК 41
Для Статьи 41 ОУК нет никаких Специальных условий контракта.
42. Цессия (Статья ОУК 42)
ОУК 42
Для Статьи 42 ОУК нет никаких Специальных условий контракта.
Раздел V. Специальные условия контракта
115
Приложение к Разделу V. Специальные условия контракта
Статья ОУК 41.2.1: положения Статьи ОУК 41.2.1 (c) раздела IV. Общие условия
контракта заменены следующим:
Мошенничество и
коррупция
41.2.1 (c)
если Поставщик и/или его персонал, агенты,
субподрядчики, консультанты, поставщики услуг, поставщики
и/или их персонал, по мнению Покупателя, был замешан в
коррупции, мошенничестве, сговоре, принуждении или
обструкционизме в процессе конкуренции за получение
Контракта или его выполнения, то Покупатель может в
уведомив Постащика предварительно за 14 дней
расторгнуть контракт и применить положения Статьи ОУК
41.1 как если бы данные действия были совершены в рамках
под-пункта Статьи 41.1.2.
(a)
Для целей настоящей Статьи:
(i) «коррупция» означает прямое или косвенное
предложение, передачу, получение или вымогание
любой ценности с целью оказать ненадлежащее
влияние на действия другой стороны;1
(ii) «мошенничество» означает любое действие или
упущение, включая дезинформацию, которое
умышленно или по неосторожности вводит в
заблуждение или пытается ввести в заблуждение
сторону2 с целью получения финансовой или
другой выгоды или уклонения от выполнения
обязательства;
1
Под «другой стороной» понимается должностное лицо, имеющие отношение к процессу закупки или к
исполнению контракта. В данном контексте «должностные лица» включают сотрудников
Всемирного Банка и других организаций, принимающих решения по закупкам, или проверяющих
их.
2
Под «стороной» понимается должностное лицо, понятия «выгода» и «обязательство» применимы к
закупочному процессу или исполнению контракта, а «действие или упущение» направлены на
оказание влияния на закупочный процесс или исполнение контракта.
Раздел V. Специальные условия контракта
116
(iii) «сговор» означает договоренность между
двумя или более сторонами имеющую
ненадлежащую цель, включая оказание
влияние на действия другой стороны3;
(iv) принуждение»
означает
нанесение
повреждения или ущерба или угроза нанесения
повреждения или ущерба напрямую или
косвенно другой стороне или собственности
другой
стороны
с
целью
оказания
ненадлежащего влияния на действия другой
стороны;4
(v)
«обструкционистская практика» это
(аа)
намеренное
уничтожение,
фальсификация, изменение или сокрытие
подтверждающей информации при проведении
расследования или ложное заявление для того,
чтобы фактически затруднить расследование
Банка
по
обвинению
в
коррупции,
мошенничестве, сговоре или насилии и
принуждении; и/или угроза, притеснение или
запугивание любой из сторон, с целью
помешать
этой
стороне
обнародовать
известные ей обстоятельства, относящиеся к
расследованию, или проводить расследование;
или
(bb)
действия, направленные на то, чтобы
фактически помешать Банку воспользоваться
своими правами на проведение инспекции и
аудита, предусмотренных параграфом 9.8,
приведенном далее.
Если работник Постащика обнаружен вовлеченным в
коррупцию, мошенничество, сговор, обструкционистская
практику во время закупа товаров то этот работник будет
уволен.
Статья ОУК 9.8: положения Статьи ОУК 9.8 Раздела IV. Общие
условия контракта заменены следующим:
3
4
Под «сторонами» понимаются участники закупочного процесса (включая должностные лица),
пытающиеся установить цены предложений на искусственном неконкурентном уровне.
Под «сторонами» понимаются участники закупочного процесса или исполнения контракта
Раздел V. Специальные условия контракта
9.8 Проверки и
аудит Банка
117
Поставщик разрешит Банку и/или лицам, назначенным
Банком, проинспектировать офисы Поставщика и/или его счета
и учетные документы, относящиеся к его работе по Контракту, и
по требованию Банка предоставит их для проверки аудиторам,
которые назначены Банком. Поставщик должен внимательно
отнестись к Статье 41.2.1(с) ОУК, которая, помимо прочего,
предусматривает, что действия, направленные на физическое
затруднение проведения Банковской инспекции или прав
аудитора, указанных в Статье 9.8 ОУК представляют собой
недопустимое действие, приводящее к расторжению контракта
(а также к признанию неправомочности по превалирующим
процедурам Банка по санкциям).
9.8
Раздел V. Специальные условия контракта
118
Раздел VI. Технические требования
119
РАЗДЕЛ VI. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
Технические требования (включая график
реализации) – для Лотов № 1-9.
A. ОСНОВАНИЕ
0.1
Покупатель
0.1.1 Исполнительной организацией настоящего Контракта является Министерство
здравоохранения и социального развития Республики Казахстан. Министерство
здравоохранения и социального развития Республики Казахстан является центральным
исполнительным органом Республики Казахстан, осуществляющим государственное
регулирование в области охраны здоровья граждан, медицинской и фармацевтической
науки,
медицинского
и
фармацевтического
образования,
санитарноэпидемиологического благополучия населения, обращения лекарственных средств,
контроля за качеством медицинских услуг. Министерство осуществляет свою
деятельность в соответствии с Конституцией и законами Республики Казахстан,
актами Президента, Правительства Республики Казахстан, иными нормативными
правовыми актами, а также Положением о Министерстве, утвержденным
Постановлением Правительства Республики Казахстан от 23 сентября 2014 года №
1005.
0.1.2 Заинтересованные стороны проекта, которые будут реализованы в результате
настоящего тендера это:
 МЗСР РК (https://www.mzsr.gov.kz/), которое определяет стратегию
электронного здравоохранения, и обеспечит поставщика необходимыми
нормативными актами и соответствующими приказами для успешной
реализации Контракта, а также обеспечит корректировку регламентов в случае
необходимости.
 Организации здравоохранения Республики Казахстан, которые будут
бенефициарами Контракта, и будут использовать результаты Контракта в
практической деятельности (далее – Организации) Подробная информация об
Организации будет предоставлена по запросу участников тендера.
0.2
Цели Покупателя
0.2.1 Общая цель МЗСР РК в области электронного здравоохранения:
Реализация электронного здравоохранения РК должна обеспечить возможность
автоматизированного получения своевременной, актуальной, достоверной, и
достаточной информации, обеспечивающей безопасную, справедливую,
Раздел VI. Технические требования
120
качественную и устойчивую систему здравоохранения, ориентированную на
потребности пациента. Это будет возможным посредством того, что все
медицинские организации и подразделения МЗСР РК будут иметь
высокоскоростной и защищенный доступ к полностью интероперабельным
системам электронного здравоохранения, основанным на безбумажной
технологии, использующим единые электронные паспорта здоровья (далее –
ЭПЗ). На центральном уровне будет организован национальный репозиторий
здравоохранения, включающий:
1)
ЭПЗ как центральный компонент, объединяющий информацию из
различных ИС медицинских организаций.
2)
хранилище высококачественных статистических, аналитических и
финансовых данных.
«Медицинские информационные системы для амбулаторно-поликлинических
организаций, стационаров и организаций смешанного типа» (далее - Системы),
приобретенные в рамках настоящего контракта, внесут значительный вклад в
достижение этого видения. Системы предназначены для автоматизации
клинических и неклинических процессов, происходящих в медицинских
организациях различных типов, а именно поликлиниках, стационарах и
организациях смешанного типа.
0.2.2 Основные цели электронного здравоохранения РК.
На
основе
анализа
приоритетных
потребностей
системы
здравоохранения РК, намеченных основными направлениями Государственной
программы «Саламатты Казахстан на 2011-2015 годы», а также ключевых
приоритетов, перечисленных в «Стратегии Казахстан 2050», касающиеся
здравоохранения, для электронного здравоохранения устанавливаются
следующие основные задачи:
1.
содействие процессу принятия клинических (медицинских)
решений;
2.
снижение количества медицинских ошибок;
3.
повышение доступности и совершенствование непрерывности
оказания медицинской помощи;
4.
повышение качества медицинских услуг;
5.
улучшение
качества
и
эффективности
принимаемых
политических, управленческих и финансовых решений;
6.
обеспечение условий для непрерывного профессионального
развития в сфере здравоохранения;
7.
повышение доступа населения к информации о своем здоровье и к
управлению вопросами их конфиденциальности;
8.
повышение рентабельности и эффективности инвестиций и
операционных расходов в здравоохранении.
Раздел VI. Технические требования
121
0.2.3 Системы, поставляемые в рамках данного тендера, будут обеспечивать
такие преимущества, как:
 Увеличение оперативности и точности отчетных форм, предоставляемых
органам управления здравоохранения;
 Сокращение непроизводительного рабочего времени работы с документацией
(оформление выписок, заполнение журналов, составление отчетных форм);
 Повышение качества принимаемых управленческих решений основанных на
доказательствах и контроль за их выполнением;
 Повышение качества оказания медицинской помощи за счет информационной
поддержки медицинской деятельности и, как следствие сокращение числа
врачебных ошибок;
 Улучшение связи между этапами оказания медицинской помощи через
электронные направления, назначения, оповещения для достижения
непрерывной и качественной медицинской помощи;
 Экономия на клинико-диагностических исследованиях за счет сокращения
числа повторных и необоснованных исследований;
 Экономия затрат на лабораторные и радиологические исследования за счет
эффективного использования дорогостоящего оборудования;
 Экономия затрат на лекарственные препараты и изделия медицинского
назначения за счет рационального назначения лекарственных средств, четкого
контроля за их расходованием и планирования закупок;
 Улучшение показателей работы медицинской организации (увеличение
пропускной способности, сокращение длительности ожидания медицинской
помощи, сокращение длительности лечения, числа осложнений, летальности);
 Снижение объемов штрафных санкций, накладываемых в случае выявления
дефектов оказания медицинской помощи;
 Контроль нецелевого использования ресурсов медицинской организации;
 Увеличение оперативности получения
диагностических подразделений;
результатов
от
лабораторий
и
 Устранение двойного ввода аналогичной информации;
 Лучший контроль за использованием лекарственных средств и уменьшение
случаев побочных эффектов и несовместимости лекарственных средств;
 Обеспечение безопасности пацинета за счет прозрачности процессов
диагностики и назначенного лечения, а также конфиденциальности
персональных данных пациентов.
0.2.4. Потенциальные бенефициары Систем.
Потенциальными прямыми бенефициарами Систем являются:
Раздел VI. Технические требования
122
 Медицинские работники - врачи, средний медицинский персонал,
использующие Системы для хранения и использования информации о
пациентах при принятии клинических решений, используя контекстную
помощь в форме клинических руководств и протоколов диагностики и
лечения и т.д.
 Менеджеры здравоохранения, использующие информацию, собранную
из различных источников данных и различных объектов;
 Сотрудники МЗСР РК, использующие данные для принятия
политических решений и внесения изменений в нормативную базу на
основе доказательств, для корректного финансирования за оказанные
медицинские услуги;
 Все информационные системы среды электронного здравоохранения с
использованием ЭПЗ, данных, классификаторов, сервисов в рамках
архитектуры СОА
 Внешние
информационные
системы,
использующие
сохраненные в приложениях электронного здравоохранения;
данные,
Потенциальные косвенные бенефициары Систем:
 Граждане Казахстана, обслуживаемые медицинскими работниками с
помощью Систем;
 Исследователи, использующие данные о лечебно-профилактическом
процессе, полученные с помощью Систем.
Ориентировочное количество рабочих мест по модулям содержится в Приложении 2
0.2.5. Информационные системы Министерства здравоохранения и социального
развития Республики Казахстан.
К информационным системам Министерства здравоохранения и социального развития
Республики Казахстан относятся следующие системы:
1.
Система «Бюро госпитализации»
2.
Система «Дополнительный компонент к тарифу ПМСП»
3.
Система «Лекарственное обеспечение»
4.
Система «Регистр беременных и женщин фертильного возраста»
5.
Система «Система управления качеством медицинских услуг»
6.
Система «Система управления медицинской техникой»
7.
Система «Система управления ресурсами»
8.
Система «Электронный регистр диспансерных больных»
9.
Система «Электронный регистр онкологических больных»
10.
Система «Электронный регистр стационарных больных»
11.
Система «Амбулаторно-поликлиническая помощь»
12.
Система «Регистр прикрепленного населения»
13.
Система «Учет больных с хронической почечной недостаточностью»
14.
Система «Регистр психических больных»
15.
Система «Регистр наркологических больных»
Раздел VI. Технические требования
123
16.
Система управления лекарственным обеспечением
17.
АИС «Поликлиника»
18.
Система «Национальный регистр больных туберкулезом»
19.
Система «Национальный регистр «Сахарный диабет»»
20.
Платформа информатизации и интероперабельности здравоохранения
Взаимодействие с ИС МЗСР РК (вышеуказанными ИС в пунктах 1-19) будет
осуществляться
посредством
сервисов
Платформы
информатизации
и
интероперабельности здравоохранения.
0.3
Акронимы, используемые в этих технических требованиях
Термин
БГ
БД
Объяснение
Бюро госпитализации
База данных
ВИЧ
Вирус иммунодефицита человека
ВКК
Врачебно-консультативная комиссия
ВСМП
Высокоспециализированная медицинская помощь
ДКПН
Дополнительный компонент подушевого норматива
РАГС
Регистр актов гражданского состояния
ЗОЖ
Здоровый образ жизни
ИИН
Индивидуальный идентификационный номер
ИКТ
Информационно-коммуникационные технологии
ИМН
Изделия медицинского назначения
ИС МЗСР РК
ИС
Информационные системы Министерства здравоохранения и
социального развития Республики Казахстан
Информационные системы
Интероперабельность Свойство или возможность различных систем работать совместно
КДУ
Консультативно-диагностические услуги
ЛИС
Лабораторная информационная система
ЛПО
Лечебно-профилактическая организация
ЛС
Лекарственнное средство
МЗСР
Министерство здравоохранения и социального развития
МИС
Медицинская информационная система
МКБ
Международная классификация болезней
МНН
Международное непатентованное название лекарственных средств
Раздел VI. Технические требования
Термин
МО
МСЭ
ПД
Платформа
ПМСП
РК
124
Объяснение
Медицинская организация
Медико-социальная экспертиза
Побочное действие лекарственных средств
Платформа информатизации и интероперабельности
здравоохранения
Первичная медико-санитарная помощь
Республика Казахстан
СДПБ
Средняя длительность пребывания больного
СКПН
Стимулирующий компонент подушевого норматива
СОА
Сервис ориентированная архитектура
СОП
Субъект оказания помощи
СУКМУ
Система управления качества медицинских услуг
ФИО
Фамилия, имя, отчество
ЭМЗ
Электронная медицинская запись
ЭПЗ
Электронный паспорт здоровья
ЭРДБ
Электронный регистр диспансерных больных
ЭРСБ
Электронный регистр стационарных больных
ЭЦП
Электронная цифровая подпись
ADO.NET
Технология, предоставляющая доступ к данным для приложений,
основанных на Microsoft .NET. Не является развитием более
ранней технологии ADO.
ASP
Активные серверные страницы, технология, предложенная
Microsoft 1996 году (англ. Active Server Page)
BAM
Мониторинг бизнес процессов (англ. Business activity monitoring)
BP
BPM
bps
BRMS
CDA
Бизнес процесс (англ. Business Process)
Управление бизнес процессами (англ. Business Process
Management)
Бит в секунду (англ. Bits per second)
Информационная система, используемая для ведения, поддержки
и исполнения бизнес-правил компании
(англ. Business Rule Management System — система
управления бизнес-правилами).
Архитектура клинического документа (англ. Clinical Document
Раздел VI. Технические требования
125
Architecture)
CPU
CRUD
CSS
DICOM
Центральный процессор компьютера (англ. Central Processing
Unit)
Операции создания, чтения, обновления и удаления данных (англ.
Create Read, Update, Delete operations)
CSS (англ. Cascading Style Sheets — каскадные таблицы стилей)
— формальный язык описания внешнего вида документа,
написанного с использованием языка разметки.
Отраслевой стандарт создания, хранения, передачи и
визуализации медицинских изображений и документов
обследованных пациентов (англ. Digital Imaging and
Communication in Medicine)
DOM
DOM (англ. Document Object Model — «объектная модель
документа») — это не зависящий от платформы и языка
программный интерфейс, позволяющий программам и скриптам
получить доступ к содержимому HTML, XHTML и XMLдокументов, а также изменять содержимое, структуру и
оформление таких документов.
ESB
Сервисная шина предприятия (англ. Enterprise Service Bus)
FHIR
Стандарт электронного обмена медицинской информацией
Стандарт FHIR – это новая спецификация от HL7, основанная на
новейших подходах в отрасли электронного здравоохранения, но
учитывающая весь накопленный опыт (реальные потребности,
успешные решения и типичные трудности) определения и
реализации стандартов HL7 v2, HL7 v3, CDA. (англ. Fast
Healthcare Interoperability Resources)
GB
Гигабайт (англ. Gigabyte)
GUI
Пользовательский графический интерфейс (англ. Graphical User
Interface)
HC
Здравоохранение (англ. Healthcare)
Help Desk
HL7
HTML
Техническая поддержка или техподдержка, обобщающая собой и
охватывающая множество услуг, посредством которых
предприятия и организации обеспечивают помощь пользователям
технологичных продуктов и услуг.
Стандарт обмена, управления и интеграции электронной
медицинской информации. (англ. Health Level 7)
Язык гипертекстовой разметки (англ. Hypertext Markup Language)
IaaS
Инфраструктура как услуга (англ. Infrastructure as a Service)
ICPC
Международный классификатор, применяемый для оказания
Раздел VI. Технические требования
126
первичной помощи (англ. 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-приложений с различными СУБД (англ. Java
Database Connectivity)
Килобайт (англ. Kilobyte)
LAN
Локальная сеть (англ. Local area network)
LDAP
Протокол прикладного уровня для доступа к службе каталогов
X.500, разработанный IETF как облегчённый вариант
разработанного ITU-T протокола DAP. (англ. Lightweight Directory
Access Protocol)
LOINC
Универсальный стандарт для идентификации медицинских
врачебных и лабораторных наблюдений. (англ. Logical Observation
Identifiers Names and Codes)
MB
Мегабайт (англ. Megabyte)
MDX
Язык запросов для простого и эффективного доступа к
многомерным структурам данных, наподобие языка SQL для
реляционных баз данных (англ. Multi-Dimensional eXpressions
Language)
ODBC
Программный интерфейс доступа к базам данных, разработанный
фирмой Microsoft, в сотрудничестве с Simba Technologies на
основе спецификаций Call Level Interface, который
разрабатывался организациями SQL Access Group, X/Open и
Microsoft. (англ. Open Database Connectivity)
OLAP
Технология обработки данных, заключающаяся в подготовке
суммарной информации на основе больших массивов данных,
структурированных по многомерному принципу (англ. Online
Analytical Processing)
OLTP
Транзакционная система — обработка транзакций в реальном
времени. Способ организации БД, при котором система работает с
небольшими по размерам транзакциями, но идущими большим
Раздел VI. Технические требования
127
потоком, и при этом клиенту требуется от системы минимальное
время отклика. (англ. Online Transactional Processing)
OWASP
Открытый проект обеспечения безопасности веб-приложений
(англ. Open Web Application Security Project)
PaaS
Платформа как услуга (англ. Platform as a Service)
PDQ
Запрос демографических данных пациента (англ. Patient
Demographic Query)
PIX
Идентификация пациентов по перекрестным ссылкам (профиль
IHE) (англ. 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
Язык разметки декларации безопасности (англ.Security Assertion
Markup Language)
SDK
Комплект средств разработки, который позволяет специалистам
по программному обеспечению создавать приложения для
определённого пакета программ, программного обеспечения
базовых средств разработки, аппаратной платформы,
компьютерной системы, игровых консолей, операционных систем
и прочих платформ (англ. Software Development Kit).
SNOMED-CT
Систематизированная медицинская номенклатура — Клинические
термины (англ. Systematized Nomenclature Of Medicine Clinical
Terms)
SOA
Сервис-ориентированная архитектура (англ.Service-oriented
architecture)
SOAP
протокол обмена структурированными сообщениями в
распределённой вычислительной среде (англ. Simple Object Access
Protocol)
SQL
Универсальный компьютерный язык, применяемый для создания,
модификации и управления данными в реляционных базах
данных (англ. Structured Query Language)
SSL
Криптографический протокол, который обеспечивает
безопасность связи. Он использует асимметричную криптографию
для аутентификации ключей обмена, симметричное шифрование
Раздел VI. Технические требования
128
для сохранения конфиденциальности (англ. Secure Sockets Layer)
SSO
Технология единого входа — технология, при использовании
которой пользователь переходит из одного раздела портала в
другой без повторной аутентификации. (англ. Single Sign On)
TCP
Один из основных протоколов передачи, данных Интернета,
предназначенный для управления передачей данных в сетях и
подсетях TCP/IP. Выполняет функции протокола транспортного
уровня в стеке протоколов TCP/IP (англ. 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
XML описание для web приложений работающих по протоколу
HTTP (как правило REST веб сервисы). Позиционируется как
эквивалент WSDL для REST. WADL моделирует ресурсы
предоставляемые сервисом и взаимосвязи между ними. (англ.
Web Application Description Language)
WCAG
Руководство по доступности Интернет-ресурсов. (англ. Web
Content Accessibility Guidelines)
WLAN
Беспроводная локальная сеть (англ. Wireless LAN)
WS
WSDL
XCA
XD-LAB
Веб сервис (англ. Web Service)
Язык описания веб-сервисов и доступа к ним, основанный на
языке XML. (англ. Web Services Description Language)
Доступ между сообществами (профиль IHE) (англ. CrossCommunity Access)
Обмен документами лабораторных отчетов между предприятиями
Раздел VI. Технические требования
129
(профиль IHE) (англ. Cross Enterprise Document Sharing of Lab
Reports)
XDS
XDS-MS
Обмен документами между предприятиями (профиль IHE) (англ.
Cross-Enterprise Document Sharing)
Обмен документами медицинских резюме (эпикризов) между
предприятиями (профиль IHE) (англ. Cross Enterprise Document
Sharing of Medical Summaries)
XML
Рекомендованный Консорциумом Всемирной паутины язык
разметки (англ. Extensible Markup Language - расширяемый язык
разметки)
XPHR
Обмен персональными медицинскими записями (англ. Exchange
of Personal Health Records)
XSL
Рекомендации консорциума W3C, описывающие языки
преобразования и визуализации XML-документов (англ.
Extensible Style sheet Language)
B. БИЗНЕС ФУНКЦИИ И ТРЕБОВАНИЯ К ХАРАКТЕРИСТИКАМ
Целью этого раздела является определение ключевых бизнес- и функциональных
требований к поставке и установке Систем.
1.1
Бизнес требования к Системам
1.1.1
Текущая ситуация ИКТ МЗСР РК
1.1.1.1. Политика Министерства здравоохранения и социального здравоохранения
РК в области электронного здравоохранения
Правительство РК приняло новую стратегию «Концепция развития
электронного здравоохранения Республики Казахстан на 2013-2020 годы», которая
определяет основные направления изменений электронного здравоохранения. В
соответствии с этой стратегией, ожидается, что новая архитектура будет служить
основой всех преобразований. Далее изложены основные свойства нового решения:
Электронное
здравоохранение
будет
основываться
на
принципах
интероперабельности, включающих: общие словари, классификаторы, номенклатуры,
Раздел VI. Технические требования
130
направленные
на
создание
единой
информационной/
семантической
интероперабельности в области электронного здравоохранения;
- Создание общих и совместно используемых регистров для электронного
здравоохранения РК: регистр пациентов, регистр медицинских работников, регистр
объектов здравоохранения, и другие регистры;
- Создание общей системы электронных паспортов здоровья (Electronic Health
Records), которая будет расположена в центре и содержать записи о здоровье всех
пациентов, и при необходимости будет реплицироваться в локальные серверы,
обеспечивая сбор, хранение и использование информации о здоровье на протяжении
всей жизни пациента и тем самым формируя механизмы для непрерывного оказания
медицинской помощи
- Предоставление вычислительной инфраструктуры, состоящий из 2-х центров
обработки данных, способных заменить друг друга в случае инцидентов;
- Установление технологии облачных вычислений, позволяющих обеспечить
соответствующие облачные сервисы: инфраструктура как услуга (IaaS), платформа как
услуга (PaaS) и программное обеспечение как услуга (SaaS);
- Эксплуатация на основе сервис-ориентированной архитектуры, что позволяет
повторно использовать функциональные возможности существующих систем и
обеспечить подключение к электронному правительству РК;
- Интеграция существующих систем и веб-приложений в платформе
интеграции/интероперабельности здравоохранения (далее – Платформа) и т.д.
Некоторые из подходов по формированию системы электронного здравоохранения
предусматривают:
- Системы электронного здравоохранения будут разработаны не только
централизованно за счет республиканского бюджета, но будет обеспечена
возможность для медицинских организаций приобретать информационные системы и
приложения самостоятельно;
- В целях обеспечения интероперабельности, будет разработан набор требований
совместимости, и информационные системы будут сертифицированы на соответствие
стандартам МЗСР РК;
- В целях стимулирования развития рынка электронного здравоохранения,
правительство будет устанавливать специальные гранты и правила софинансирования
для ЛПО желающих компьютеризировать свою медицинскую деятельность;
- Правительство будет оценивать и контролировать потенциальные риски и принимать
решения, которые будут способствовать решению рисков (например, пропускная
способность каналов связи, выравнивание между потребностями здравоохранения и
ИКТ, обеспечения совместимости и т. д.);
- Министерство здравоохранения и социального развития ускорит процесс создания
правил и стандартов для улучшения взаимодействия между участниками процесса
электронного здравоохранения.
Общая архитектура Национальной системы ЭПЗ представлена на рисунке 1 ниже.
Системы приобретенные в рамках текущего тендера закодированы как МИС
(выделено розовым) в желтом квадрате в правой нижней части рисунка 1
Раздел VI. Технические требования
131
Рис.1. Архитектура взаимодействия покупаемой информационной системы с
национальными ресурсами электронного здравоохранения
Более детальное описание изложено в «Концепции развития электронного
здравоохранения Республики Казахстан на 2013-2020 годы», доступной на веб-сайте
МЗСР РК.
1.1.2
Принципы, которым должны следовать Системы
Следующие принципы применяются к разработке, конфигурации и использованию
Систем:
 Принцип законности, который предполагает создание, использование и
сопровождение информационных систем в соответствии с национальной
правовой базой с международными нормами и стандартами в этой области;
 Принцип безопасных данных, который обеспечивает ввод данных в Систему
только с помощью прошедших проверку и авторизованных каналов;
 Принцип информационной безопасности, который предполагает обеспечение
надлежащего уровня целостности, избирательности, доступности и
Раздел VI. Технические требования
132
эффективности для защиты данных от потери, изменения, уничтожения и
несанкционированного доступа;
 Принцип
конфиденциальности
данных,
который
предполагает
осуществление процедур, которые будут гарантировать доступ к данным только
в соответствии с национальной политикой и международными стандартами к
конфиденциальности личных данных, доступ в соответствии с согласием
пациента, возможностью шифровать сохраненные данные;
 Принцип прозрачности, который предполагает, что Система является
модульной структурой, и будет использовать прозрачные/ открытые стандарты
в области ИКТ;
 Принцип
расширения,
который
предполагает
расширение
и
совершенствование Системы с помощью новых функций и улучшения
существующей функциональности;
 Принцип приоритета первого лица/ уникального центра, который допускает
существование должностного ответственного лица высокого уровня, который
имеет достаточно прав для принятия решений и координации деятельности по
созданию, интеграции и использованию Системы;
 Принцип
масштабируемости,
который
предполагает
постоянную
производительность приложений и взаимосвязей с приращением объемов
данных и пользователей;
 Принцип простоты и удобства пользователей, который предполагает, что все
функции и инструменты, доступные для целевых ролей, основаны на
визуальных инструментах, эргономичны и интуитивно понятны.
1.1.3 Бизнес-требования к Системам
Примечание 1. Следующие ключевые слова (т.е. нормативные глаголы) БУДУТ
использоваться, чтобы передать требования соответствия.
• СЛЕДУЕТ - для указания обязательного требования, подлежащего исполнению
(реализации) для того, чтобы соответствовать. Синонимом «ОБЯЗАН». Другой
используемый синоним «ДОЛЖЕН».
• НЕ СЛЕДУЕТ - чтобы указать запрещенное действие. Синоним «запрещено».
• СЛЕДОВАЛО БЫ - для указания дополнительного рекомендуемого действия,
которое особенно подходит, без упоминания или исключения других. Синоним
«разрешено и рекомендовано».
• МОЖЕТ - чтобы указать необязательные, допустимые действия. Синоним
«разрешено».
Примечание 2. В таблицах с бизнес- и функциональными
используются следующие категории (типы) или требования:
требованиями,
Раздел VI. Технические требования
133
M - означает минимальное обязательное требование; такое требование, которому
поставляемое решение обязательно должно соответствовать; полное или частичное
отсутствие соответствия такому требованию может привести к отклонению
предложения участника.
D - желательные требования; отсутствие соответствия данному требованию не
приведет к отклонению предложения участника, а соответствие позволит повысить
конкурентоспособность предложения.
I - означает информация, добавляется для прояснения других требований.
Ссылка на требования в тексте будет отличаться от ссылки на главы и части в явном
виде:
Ссылка на требования явно будет содержать слово «требование», «req.» или R,
например R1.1 - ссылка на требование 1.1;
Ссылки на главы будут с префиксом «глава», «раздел», или р, например, «p.1.1.1»
указывает на раздел 1.1.1 и не является требованием.
Таблица ниже содержит список бизнес-требований, которым должны соответствовать
поставляемые Системы и связанные с ней системы/сервисы.
1.1.3.1 Общие бизнес-требования
№
Тип
Требование
Общие Бизнес требования к Системе
R1
R1.1
M
Механизм лицензирования для Системы в рамках данного контракта
предоставляет право использовать все ее модули и составные части в
рамках Организации для количества пользователей достаточного для
полноценного функционирования медицинской организации (размер
организации можно оценить из описания в Приложении 2), в течение
неограниченного времени, неограниченного количества серверов, снимая
все прочие возможные ограничения. Не допускаются ежегодные
лицензионные сборы; полная стоимость лицензии включает в себя все
расходы на лицензирование Системы.
R1.2
M
В рамках данного Контракта должна быть обеспечена
интероперабельность Системы с национальной системой электронного
здравоохранения согласно требованиям R7. Общая схема взаимодействия
с национальной системой электронного здравоохранения представлена на
Рисунке 1.
R1.3
M
Обобщенная архитектура комплексной информационной системы
здравоохранения, которой должна соответствовать Система, представлена
на рисунке 2
R1.4
M
Модули и/или составные части системы должны иметь возможность
обмена информацией между собой используя http(s) -протокол
R1.5
M
Система должна иметь сервис-ориентированную архитектуру,
Раздел VI. Технические требования
134
поддерживающую строго определенные и платформо-независимые
интерфейсы взаимодействия.
R1.6
M
По крайней мере следующий функционал, рассчитанный на
использование широким кругом пользователей (пациенты, врачи по
удаленному доступу, руководители) должен быть реализован в качестве
веб-приложения:
- ведение демографических данных пациента
- ведение жалоб пациента
- ведение аллергологического анамнеза
- ведение анамнеза жизни
- ведение перенесенных заболеваний
- ведение анамнеза настоящего заболевания
- ведение объективный статус осмотра пациента
- ведение локального статуса осмотра пациента
- ведение информации о реакциях на лекарственные препараты
- ведение направлений на лабораторные исследования
- ведение врачебных назначений
- ведение направлений на консультативно-диагностические услуги
- просмотр результатов лабораторных исследований
- просмотр результатов консультативно-диагностических услуг
- ведение проведенных лечебных мероприятий
- формирование отчетных форм
- ведение дополнительных записей врача
R1.7
M
Система должна иметь способность тонкой настройки, чтобы обеспечить
конфигурацию под потребности конкретной Организации без
необходимости новой разработки (или включая малую доработку)
R1.8
M
Поставщик в рамках данного Контракта должен обеспечить
интероперабельность Системы с Национальными инструментами ЭПЗ
(Репозиторий ЭПЗ, Национальные классификаторы и идентификаторы,
аналитическое хранилище, ЭПЗ-веб-сервисы) в соответствии с R7
R1.9
M
Должна быть обеспечена интеграция Системы с внедренной
бухгалтерской системой «1C». Уровень интеграции должен быть
определен в ходе реализации Контракта и согласован с организацией, в
которой осуществляется внедрение Системы
R1.10
M
Система должна обеспечивать конфиденциальность персональных
данных в процессе сохранения и передачи: шифрование
конфиденциальных данных в базе данных, шифрование данных при
передаче через каналы, использование безопасных протоколов передачи и
т.д.
Раздел VI. Технические требования
135
M
Система должна обеспечивать возможность использования электронноцифровой подписи для подписания и аутентификации электронных
документов, файлов и частей документов. Необходимость использования
электронно-цифровой подписи должна быть конфигурируемой на уровне
системного администратора. Более подробно о требованиях к
электронной подписи см. R5.15.
M
Система должна быть полностью работоспособной и сдана Покупателю
«под ключ» в соответствии с R14.2. Для выполнения данного требования,
Поставщик должен, при необходимости, добавить недостающие части,
функциональность и технологические решения, включая стоимость
отсутствующих частей в таблице стоимостей в раздел «другие»
R1.13
M
Поставщик должен обеспечить не менее чем, но не ограничиваясь,
следующее: конфигурацию, развертывание, установку, тестирование
Системы и обучение пользователей, администраторов (и другого
персонала при необходимости).
R1.14
M
Поставщик должен участвовать в процессе сертификации Системы
совместно с Поставщиком Платформы с целью проверки и сертификации
интероперабельности с национальными ресурсами и инструментами ЭПЗ,
в процедурах проведения аттестации и испытаний Системы
R1.15
M
Поставщик должен обеспечить гарантийное обслуживание Системы в
течение 3 лет со дня передачи системы в эксплуатацию Покупателю в
соответствии с R12.4
R1.16
M
В случае если для полноценного функционирования Системы «под ключ»
необходимо наличие дополнительного лицензионного программного
обеспечения, Поставщик обязан обеспечить наличие всех лицензий за
свой счет и их передачу в собственность Покупателя в рамках данного
Контракта.
R1.17
M
Поставщик системы должен поставить в Организации конфигурацию
Системы согласно Таблице 1. Составляющие компоненты Системы
уточнены в таблице 2.
R1.18
M
Минимальные требования для каждого модуля должны соответствовать
требованиям раздела R2
R1.19
M
Поставщик в составе конкурсного предложения в данном тендере должен
предоставить предлагаемую редакцию технической спецификации с
соблюдением формата и структуры данного документа
R1.11
R1.12
Раздел VI. Технические требования
136
R1.20
D
Система должна иметь возможности интеграции со средами разработки
(IDE), как минимум для Java и Net Framework. Система должна иметь в
комплекте средства разработки (SDK), включающий в себя:
документацию, примеры кода как минимум для Java и Net Framework, для
конфигурирования функции Системы. Должна быть возможность
расширения функциональности Системы с ипользованием средств
разработки (SDK), входящих в состав Системы.
R1.21
М
Механизм лицензирования для Системы в рамках данного контракта не
должен ограничивать изменения, вносимые с помощью средств
разработки (SDK), входящих в состав Системы. Внесение изменений с
помощью средств разработки (SDK), входящих в состав Системы, не
должно влиять на условия гарантийного обслуживания Системы.
Внесение изменений в Систему специалистами Заказчика допускается
после сдачи Системы в эксплуатацию.
R1.22
M
Поставщик должен обеспечить обслуживание и техническую поддержку,
включая предоставление новых версий продуктов (согласно R12.3).
R1.23
М
Время отклика сервисов и компонентов Системы должно быть не более 35 секунд, для не менее 80% случаев ввода данных или запросов на
просмотр данных (при скорости канала 1 Мб/с и времени отклика не
более 100 мс).
R1.24
I
Под возможностью автоматического уведомления пациентов
(посредством электронной почты и/или SMS) понимается наличие
данного функционала в Системе. Данное требование не распространяется
на оплату затрат на рассылку SMS и/или организацию доступа к сети
интернет.
R1.25
М
Поставщик должен документировать и передать в электронном виде
конфигурационные файлы,и исходный код, компонентов Системы,
разработанные в рамках данного контракта.
R1.26
М
Система должна иметь тонкий клиент, для взаимодействия
оборудованием допускается использование толстого клиента.
R1.27
M
Система должна отвечать следующим требованиям в отношении
отчетности:
с
 Все аналитические формы и отчетные формы должны иметь
возможность экспорта в форматы .xls, xlsx, .docx, doc, .pdf, .csv,
.html, .xml.
 Время формирования аналитических и отчетных форм не должно
превышать 1 мин. При этом для 95 % случаев, время
формирования аналитических и отчетных форм не должно
Раздел VI. Технические требования
137
превышать 30 секунд.
 В
системе
должно
быть
предусмотрена
возможность
формирования аналитических и отчетных форм по расписанию.
 В системе должно быть предусмотрена возможность отправки
сформированной аналитической и отчетной формы на указанный
адрес электронной почты.
Раздел VI. Технические требования
138
Рис.2. Обобщенная архитектура комплексной информационной системы
здравоохранения.
Таблица 1. Тип поставляемой конфигурации для организаций – бенефициаров
Лот Название
№
организации бенефициара
Адрес и
контакты
Тип конфигурации
системы (в
соответствии с
Таблицей 2)
1
УстьКаменогорская
городская
больница №1
Старокожев
Стационар
Юрий
Александрович
8-7232-75-28-87
ВКО г. УстьКаменогорск,
ул.Абая, 18
2
Городская
клиническая
больница №4 г.
Алматы
Аманов Ануар
Турсунжанович
+7 (727)
3003601 г.
Алматы,
Турксибский
район, ул.
Папанина д.220
Стационар
3
Центр матери и
ребенка г. УстьКаменогорск
Рахимова Рая
Жангалиевна 87232-57-38-76
Стационар+поликлиника
г. Устькаменогорск,
ул.Утепова
35,37
4
Городская
поликлиника
№11 г.Алматы
Карибаева
Гульжакан
Абатовна 87272-52-21-21
г.Алматы
Жетысуский
район ,ул.
Жумабаева 87
Поликлиника
Примечания
Раздел VI. Технические требования
139
5
Региональный
диагностический
центр г.Алматы
Куралбаев
Поликлиника
Бекмахан
Сыбанбаевич 87273-75-26-12
г.Алматы
ул.Ауезова, 57
6
Поликлиника №1
г.Костанай
Игимбаева
Ольга
Владимировна
8 7142 56-82-23
г.Костанай
пр.Аль-Фараби
112
Поликлиника
7
Центральная
районная
больница
Жуалынского
района
Жамбыльской
области
Жумашев
Сейтхан
Шерелханулы
(8-726-35) 2-2149, 2-21-98
Жамбылская
область,
Жуалынский
район с Б.
Момышулы,ул.
С.Бейбарыс 1
Стационар+поликлиника Состоит из 36
филиалов
расположенных
удаленно в
рамках одного
района
8
Поликлиника №7
г.Астаны
Куанышева
Айгуль
Шалабаевна 87172-79-36-23
Поликлиника
г.Астана, пр.
Ш.
Кудайбердыулы
25,29
9
Городская
больница №1
г.Астаны
Абдуов Марат
Стационар+поликлиника
Карсыбекович
8-7172-23-16-01
г. Астана, пр.
Кошкарбаева,
66
Таблица 2. Модульный состав МИС для различных типов Организаций
Модуль
Стационар
Поликлиника
Раздел VI. Технические требования
140
Модуль «1. Регистратура»
-
+
Модуль «2. Участковый врач»
-
+
Модуль «3. Ведение профилактических
осмотров»
-
+
Модуль «4. Профильный специалист»
+
+
Модуль «5. Заведующий отделением
поликлиники»
+
-
Модуль «6. Медицинская статистика
поликлиники»
-
+
Модуль «7. Приемный покой»
+
-
Модуль «8. Врач стационара»
+
-
Модуль «9. Медсестра стационара»
+
-
Модуль «10. Питание»
+
-
Модуль «11. Дневной стационар»
+
+
Модуль «12. Заведующий отделением
стационара»
+
+
Модуль «13. Главный врач»
+
+
Модуль «14. Медицинская статистика
стационара»
+
+
Модуль «15. Процедуры и
манипуляции»
+
+
Модуль «16. Администратор»
+
+
Модуль «17. Лабораторная
информационная система»
+
+
Модуль «18. PACS» (Picture Archiving
and Communication System)
+
+
Модуль «19. Диагностические
исследования»
+
+
Модуль «20. Аптека»
+
+
Раздел VI. Технические требования
Модуль «21. Кадры»
141
+
+
1.1.3.2 Требования к составу процессов, поддерживаемых и автоматизированных
Системой
Примечание 1:
Разделение на модули является условным и не обязательным для строгого соблюдения.
Необходимым условием является обязательное наличие данных функций.
Примечание 2:
При упоминании форм с приставкой /у описываются (первичные) учетные
формы утвержденные приказом и.о. МЗ РК №907 от 23 ноября 2010 года «Об
утверждении форм первичной медицинской документации организаций
здравоохранения»
При упоминании форм без приставки /у описываются (вторичные) отчетные
формы (ежемесячные, ежеквартальные, ежегодные) утвержденные приказом МЗ РК
№128 от 06 марта 2013 года «Об утверждении форм, предназначенных для сбора
административных данных субъектов здравоохранения»
R2
Требования к автоматизированным процессам
R2.1
Модуль «1. Регистратура»
R2.1.1
М Ведение графиков работы врачей, выполнения услуг, работы
аппаратов. Данный процесс включает, как минимум:
R2.1.1.1
M Создание графика работы врача с возможностью выбора данных
врача (ФИО, должность, специальность, структурное подразделение)
из перечня сотрудников данной организации.
R2.1.1.2
M Проверка на наличие уже существующего графика на данный
промежуток времени (дата, время), для данного врача, кабинета,
аппарата и информирование пользователя о его наличии при
создании графика работы врача, выполнения услуги или работы
аппарата
R2.1.1.3
M Поиск графика среди существующих по дате, времени, врачу,
специальности врача, услуге, аппарату и их сочетаниям
R2.1.1.4
M При создании графика работы врача, выполнения услуги или работы
аппарата возможность осуществлять привязку врача, услуги и
аппарата между собой. Данная привязка не является обязательной к
заполнению
Раздел VI. Технические требования
142
R2.1.1.5
M При создании графика выполнения услуги возможность выбора
услуг из перечня услуг, на выполнение которых имеет право
Организация и специалист, ее выполняющий
R2.1.1.6
M При создании графика работы аппаратов возможность выбора
аппарата из перечня аппаратов Организации
R2.1.1.7
M Возможность создания, редактирования и удаления графиков
R2.1.1.8
M При удалении или редактировании графиков при наличии уже
записанных пациентов возможность автоматического подбора
возможного ближайшего подходящего времени у аналогичного
специалиста и возможность выбора определенного времени
пользователем
R2.1.1.9
M При удалении или редактировании графиков должна быть
возможность автоматического уведомления пациента об
изменившихся дате, времени, месте приема по электронной почты
и/или SMS
R2.1.1.10
M Формирование следующих отчетных форм:
1.
Сводная информация о графиках работы врачей, в разрезе
подразделений, смен, выполнения услуг, работы аппаратов.
Отчет об изменениях записи пациентов вследствие изменения
графиков.
2.
R2.1.2
М Запись пациента на прием с выдачей талона на прием. Данный
процесс включает, как минимум:
R2.1.2.1
M Запись пациента сотрудником регистратуры, врачом во время
приема, пациентом через Интернет с выдачей талона на прием
R2.1.2.2
M Регистрация новых пациентов с заполнением персональных данных,
в том числе занесение данной информации из ИС МЗСР РК
R2.1.2.3
M Выбор пациента из базы данных пациентов по ИИН или по ФИО,
дате рождения
R2.1.2.4
M Печать маршрутного листа на выданные талоны с указанием врача,
кабинета, даты и времени приема, при необходимости указания
дополнительной информации (способа подготовки пациента к
посещению и т.п.)
R2.1.2.5
M Регистрация выдачи и получения амбулаторных карт пациентов
R2.1.2.6
M Отмена записи сотрудником регистратуры, врачом во время приема,
Раздел VI. Технические требования
143
пациентом через Интернет
R2.1.2.7
M Формирование «Листа ожидания» для заполнения освободившегося
в результате отмены записи времени приема с автоматическим
уведомлением пациента в случае его записи на освободившееся
время приема посредством электронной почты и/или SMS
R2.1.2.8
M Возможность бронирования времени приема в графике (одиночное,
групповое) с регулируемым временем снятия брони
R2.1.2.9
M Автоматическое предотвращение записи пациента к нескольким
специалистам в одно и тоже время приема, а также предотвращение
записи нескольких пациентов в одно и тоже время к одному
специалисту
R2.1.2.10
M Поиск времени для записи среди существующих графиков по дате,
времени, врачу, специальности, услуге, аппарату и их сочетаниям
R2.1.2.11
M Формирование следующих отчетных форм:
1. Отчет о количестве записанных на прием (по врачу, услуге,
аппарату, отделению, Организации)
2. Отчет о количестве свободных мест (по врачу, услуге,
аппарату, отделению, Организации)
3. Отчет об отмененных визитах
4. Отчет о неявившихся пациентах
5. Отчет о бронировании посещений
6. Отчет по обратившимся пациентам (за отчетный период, в
разрезе направивших МО, в разрезе специалистов, в разрезе
услуг)
R2.1.3
M Ведение журнала вызовов на дом. Данный процесс включает, как
минимум:
R2.1.3.1
M Регистрация вызова на дом, принятого по телефону, посредством
Интернет и при обращений пациента в МО
R2.1.3.2
M Регистрация отмены вызова на дом по инициативе пациента
R2.1.3.3
M Регистрация передачи врачу вызова на дом
R2.1.3.4
M Регистрация факта выполнения вызова на дом с детализацией
результатов вызова
R2.1.3.5
M Регистрация необходимости повторного вызова и его даты
Раздел VI. Технические требования
144
R2.1.3.6
M Формирование листа нераспределенных вызовов: в разрезе участков,
по организации в целом
R2.1.3.7
M Формирование листа вызовов для исполнения врачом с указанием
ФИО пациента, диагноза, адреса, телефона, примечаний
R2.1.3.8
M Формирование следующих отчетных форм:
1. Отчет о вызовах на дом (открытых, принятых, исполненных,
отмененных) по врачу, пациенту, участку
2. Отчет о времени поступления и выполнения вызовов
R2.1.4
M Ведение журнала активов (вызовы на дом по инициативе
медицинских работников). Данный процесс включает, как минимум:
R2.1.4.1
M Разделение активов на группы – активы стационара, активы
поликлиники, активы новорожденных, активы скорой, активы
беременных, родильниц
R2.1.4.2
M Регистрация актива, принятого по телефону, через Интернет
R2.1.4.3
M Регистрация группы активов путем импорта файла – таблицы
установленного образца
R2.1.4.4
M Регистрация отмены актива
R2.1.4.5
M Регистрация передачи актива врачу
R2.1.4.6
M Регистрация факта выполнения актива с детализацией результатов
актива
R2.1.4.7
M Регистрация необходимости повторного актива и его даты
R2.1.4.8
M Формирование листа нераспределенных активов в разрезе участков,
по организации в целом
R2.1.4.9
M Формирование листа активов для исполнения врачом с указанием
ФИО пациента, диагноза, адреса, телефона, примечаний
R2.1.4.10
M Формирование следующих отчетных форм:
1. Отчет об активах (открытых, принятых, исполненных,
отмененных) по врачу, пациенту, участку
2. Отчет о времени регистрации и выполнения активов
R2.1.5
M Ведение первичной учетной документации на уровне регистратуры в
соответствии с действующими нормативными правовыми актами РК.
Раздел VI. Технические требования
145
Данный процесс включает, как минимум ведение следующих
учетных форм:
R2.1.5.1
M
Форма 040/у
Форма 025-4/ у
Форма 025-9/у
Форма 025-5/у
Форма 031/у
R2.1.6
M Формирование аналитических форм на уровне регистратуры, а также
статистических таблиц в соответствии с действующими
нормативными правовыми актами РК.
R2.1.7
M Взаимодействие с ИС МЗСР РК. Данный процесс включает, как
минимум:
R2.1.7.1
M Передача информации о графиках приема врачей, выполнения
услуги, работы аппаратов.
R2.1.8
M Регистрация фактов прикрепления/ открепленния обслуживаемого
населения медицинской организации.
R2.2
Модуль «2. Участковый врач»
R2.2.1
М Ведение амбулаторной карты пациента. Данный процесс включает,
как минимум:
R2.2.1.1
M Просмотр списка пациентов, записавшихся на прием
R2.2.1.2
M Создание амбулаторной карты пациента
R2.2.1.3
M Создание и редактирование шаблонов в том числе формирование
медицинских документов и записей, консультаций, протоколов
осмотров, дневниковых записей с помощью шаблонов и
возможностью прикрепления файлов (изображений, видеозаписи,
звукозаписи) с привязкой пользовательских шаблонов к учетной
записи пользователя
R2.2.1.4
M Создание медицинских записей на основе стандартных или
пользовательских шаблонов
R2.2.1.5
M Редактирование и удаление медицинских записей, подписанных
ЭЦП, должно быть заблокировано
Раздел VI. Технические требования
146
R2.2.1.6
M Вывод на печать заполненных медицинских записей для
формирования бумажной версии амбулаторной карты
R2.2.1.7
M Возможность выборки медицинских записей по определенному
признаку (посещения, диагнозы, даты, диагностические
исследования, лабораторные анализы, услуги, источники
финансирования и т.д.)
R2.2.1.8
M Отчетная форма об изменении числовых показателей пациента во
времени (антропометрические показатели, функциональные
показатели, лабораторные данные и т.д.)
R2.2.2
M Создание направлений на консультативно-диагностические услуги
внутренние (в пределах данной организации) и внешние (в другие
медицинские организации). Данный процесс включает, как
минимум:
R2.2.2.1
M Создание направления на КДУ внутри организации с возможностью
записи на определенное время
R2.2.2.2
M Создание направления на КДУ в иные медицинские организации с
возможностью записи на определенное время
R2.2.2.3
M Согласование направлений на отдельные виды услуг с заведующим
отделением
R2.2.2.4
M Формирование рекомендаций по подготовке к КДУ на основе
стандартных шаблонов
R2.2.2.5
M Удаление направлений (некорректных, по инициативе пациента,
автоматическое при неявке пациента)
R2.2.2.6
M Мониторинг исполнения клинико-диагностических услуг
назначенных пациенту, просмотр данных о выполнении назначения,
включая результаты.
R2.2.2.7
M Согласование и отклонение заявок на дополнительные КДУ
R2.2.2.8
M Формирование отчетных форм:
1. Отчет о созданных направлениях (внутренние, внешние) по
услугам, источникам финансирования, по уровням оказания
медицинской помощи (районный, областной/городской,
республиканский)
2. Пофамильный список направленных на консультативно-
Раздел VI. Технические требования
147
диагностическую помощь
3. Отчет о направлениях (открытые, выполняющиеся,
выполненные, отклоненные, внешние, внутренние)
R2.2.3
M Оформление плановой госпитализации (круглосуточный стационар и
стационарозамещающие технологии). Данный процесс включает, как
минимум:
R2.2.3.1
M Формирование выписки из медицинской карты амбулаторного
больного (форма 027/у)
R2.2.3.2
M Формирование:
- шаблонов по минимальным стандартам исследований на
догоспитальным этапам по уровням МО
- направлении и талона на плановую госпитализацию
R2.2.4
M Формирование врачебных назначений лекарственных средств и/или
процедур и манипуляций. Данный процесс включает, как минимум:
R2.2.4.1
M Создание рецептов на лекарственные средства (платные, бесплатные,
льготные) и по наркотическим средствам с ограниченным доступом
определенной категории врачей и с описанием способов приема,
дозировок и т.д.
R2.2.4.2
M Контроль назначений в соответствии с установленными
максимальными разовыми дозами в зависимости от возраста, пола,
веса и т.д.
R2.2.4.3
M Контроль назначений в соответствии с формуляром Организации и
Республики Казахстан. Результаты обеспечения льготными
лекарственными препаратами диспансерных больных и других
категорий граждан
R2.2.4.4
M Подписание рецептов с помощью ЭЦП
R2.2.4.5
M Проверка наличия лекарственного препарата в аптеке. Данное
требование должно быть реализовано путем взаимодействия с
модулем «Аптека»
R2.2.4.6
M Создание направлений на выполнение процедур с указанием
лекарственных средств и их дозировкой
R2.2.4.7
M Формирование рекомендаций по подготовке к процедурам на основе
стандартных шаблонов
R2.2.4.8
M Контроль за выполнением назначений и отпуском лекарственных
Раздел VI. Технические требования
148
препаратов
R2.2.4.9
M Предоставление справочной информации по рекомендуемым
назначениям, согласно утвержденных клинических руководств и
протоколов диагностики и лечения
R2.2.4.10
M Формирование листа врачебных назначений (форма 004-1/у)
R2.2.4.11
M Формирование отчетных форм:
1. Отчет о созданных рецептах (МНН, форма, дозировка, способ
приема и т.д.)
2. Пофамильный список получивших рецепты
3. Пофамильный список получивших рецепты, по льготным
категориям
R2.2.5
M Ведение первичной учетной документации на уровне участкового
врача в соответствии с действующими нормативными правовыми
актами РК. Данный процесс включает, как минимум ведение
следующих форм:
R2.2.5.1
M 001-2/у, 001-3/у, 001-4/у, 001-5/у, 001-6/у, 003-2/у, 004-1/у, 025/у
(025-3, 025-4), 025-3/у, 025-5/у, 025-7/у, 025-8/у, 026/у,
026-1/у, 026-2/у, 030/у, 032/у, 036/у, 038/у, 039/у, 040/у,
052/у, 053/у, 054/у, 058/у, 060/у, 063/у, 064/у, 070/у, 072/у, 075/у,
086/у, 088/у 088-1/у, 094/у, 095/у, 106/у-12, 106-2/у-12, 112/у, 130/у,
132/у, 133/у, 138/у, 278/у, ТБ 15/у, ТБ 05/у,
R2.2.6
M Формирование аналитических форм на уровне участкового врача, а
также статистических таблиц в соответствии с нормативноправовыми актами. Данный процесс включает, как минимум
следующие формы отчетных форм:
R2.2.7
M
1. Ведомость учета посещений в поликлинике (амбулатории),
диспансере, консультации и на дому (039/у), в том числе и в
разрезе участковых врачей ПМСП
2. Отчет о выполнении скрининговых обследований согласно
приказа МЗ РК № 685от 10 ноября 2009 года, в том числе и в
разрезе участковых врачей ПМСП
3. Мониторинг выполнения обязательных ежегодных
флюорографических обследований населения, в том числе и в
разрезе участковых врачей ПМСП
4. Мониторинг выполнения ежемесячных т ежегодных планов
Раздел VI. Технические требования
149
по иммунопрофилактике форма №5, 6 приказ МЗ РК 128 от 06
марта 2013 года, в том числе и в разрезе участковых врачей
ПМСП
5. Отчет о поствакциональных осложнениях в разрезе
участковых врачей по видам проф. прививок, по возрастам и
исходам, в том числе и в разрезе участковых врачей ПМСП
6. Отчет о движении диспансерных больных, в том числе и в
разрезе участковых врачей ПМСП
7. Отчет о движение диспансерных больных с ХПН с указанием
о проведении заместительной терапии (гемодиалиаз или
перитонеальный, трансплантация почки и др.), в том числе и в
разрезе участковых врачей ПМСП
8. Отчет о рождаемости, в том числе и в разрезе участковых
врачей ПМСП
9. Отчет о смертности, в том числе и в разрезе участковых
врачей ПМСП
10. Отчет об инвалидности, в том числе и в разрезе участковых
врачей ПМСП
11. Отчет о направлении и госпитализации, в том числе плановой
госпитализации в разрезе участковых врачей ПМСП
12. Отчет по мероприятиям ЗОЖ, в том числе и в разрезе
участковых врачей ПМСП
13. Отчет о количестве и структуре прикрепленного населения, в
том числе и в разрезе участковых врачей ПМСП
14. Отчет о числе заболеваний, зарегистрированнных у больных,
проживающих в районе обслуживания медицинской
организации и контингентах больных, состоящих под
диспансерным наблюдением (форма 56, 12), в том числе и в
разрезе участковых врачей ПМСП
15. Отчет о контингентах больных, получивших
стационарозамещающую помощь (форма 24), в том числе и в
разрезе участковых врачей ПМСП
16. Отчет о медицинской помощи детям (форма 31), в том числе и
в разрезе участковых врачей ПМСП
17. Отчет по детской инвалидности (форма 52), в том числе и в
разрезе участковых врачей ПМСП
18. Отчет об использовании коечного фонда медицинских
организаций, оказывающих стационарную и
стационарозамещающую помощь (форма 21), в том числе и в
Раздел VI. Технические требования
150
разрезе участковых врачей ПМСП
19. Отчет о доставленных пациентов скорой медицинской
помощи, в том числе и в разрезе участковых врачей ПМСП
R2.2.8
M Ведение учета листов временной нетрудоспособности. Данный
процесс включает, как минимум:
R2.2.8.1
M Регистрация листа временной нетрудоспособности
R2.2.8.2
M Продление листа временной нетрудоспособности
R2.2.8.3
M Закрытие листа временной нетрудоспособности
R2.2.8.4
M Отправка листа временной нетрудоспособности на согласование с
заведующим отделением или с ВКК
R2.2.8.5
M Формирование направления на МСЭ (форма 088/у)
R2.2.8.6
M Формирование отчетных форм:
1. Отчет о выданных листах временной нетрудоспособности
2. Отчет о направленных на МСЭ
R2.2.9
M Взаимодействие с ИС МЗСР РК. Данный процесс включает, как
минимум:
R2.2.9.1
M Обмен информацией в соответствии с требованиями стандартов ЭПЗ
и ЭМЗ. Подробнее см. R7.2.1.
R2.2.9.2
M Обмен информацией о госпитализации
R2.2.9.3
M
Обмен информацией о выполненных услугах
R2.2.9.4
M
Обмен клинической информацией (заключительные диагнозы,
результаты консультаций, осмотров и т.д.)
R2.2.9.5
M
Обмен информацией о направлениях на КДУ
R2.2.9.6
M
Обмен информацией о назначениях процедур
R2.2.9.7
M
Обмен информацией о рецептах
R2.3
Модуль «3 Ведение профилактических осмотров»
Раздел VI. Технические требования
151
R2.3.1
М Формирование контингентов подлежащих профилактическим
осмотрам целевых групп населения (скрининг) и учет их проведения
в соответствии с действующими нормативными правовыми актами
РК Данный процесс включает, как минимум:
R2.3.1.1
M Формирование пофамильных списков для прохождения
профилактических осмотров целевых групп населения (скринингов)
из числа прикрепленного населения в соответствии с требованиями
нормативно-правовых актов
R2.3.1.2
M Возможность автоматического уведомления пациентов (посредством
электронной почты и/или SMS) о необходимости прохождения
скрининговых осмотров
R2.3.1.3
M Формирование маршрутных листов для прохождения скринингов
R2.3.1.4
M Отметка о выполнении исследований в рамках скринингов с
указанием результата и/или заключения
R2.3.1.5
M Автоматическое формирование направлений к специалистам в
рамках прохождения скрининга
R2.3.1.6
M Заполнение карты скринингового осмотра
R2.3.1.7
M Формирование заключения о прохождении скрининга
R2.3.1.8
M Формирование отчетных форм:
1. Отчет о контингентах подлежащих скрининговому осмотру
(по видам скрининга, участку, возрастно-половой структуре)
2. Отчет о прохождении скринингов
3. Отчет о заболеваниях, выявленных в ходе скрининга
R2.3.2
M Учет других видов профилактических осмотров периодических и
очередных при устройстве на работу. Данный процесс включает, как
минимум:
R2.3.2.1
M Формирование пофамильных списков для прохождения
профилактических осмотров
R2.3.2.2
M Формирование маршрутных листов для прохождения
профилактических осмотров
R2.3.2.3
M Отметка о выполнении исследований в рамках профилактических
осмотров с указанием результата и/или заключения
Раздел VI. Технические требования
152
R2.3.2.4
M Автоматическое формирование направлений к специалистам в
рамках прохождения профилактических осмотров
R2.3.2.5
M Заполнение карты профилактического осмотра
R2.3.2.6
M Формирование заключения о прохождении профилактического
осмотра с выдачей справки
R2.3.2.7
M Формирование отчетных форм:
1. Отчет о выполненных профилактических осмотрах (по видам
скрининга, участку, возрастно-половой структуре)
2. Отчет о заболеваниях, выявленных на профилактическом
осмотре
3. Отчет о контигентах, подлежащих периодическим
профилактическим осмотрам
R2.3.3
M Ведение первичной учетной документации на уровне врача в
соответствии с действующими нормативными правовыми актами РК
Данный процесс включает, как минимум ведение следующих
учетных форм:
R2.3.3.1
M
R2.4
025/у, 025-4/у, 025-5/у, 025-7/у, 025-8/у, 030/у, 032/ у, 040/у, 086/у,
108/у, 108-1/у, 112/у, 131/у, 245/у
Модуль «4. Профильный специалист»
R2.4.1
М Создание и ведение амбулаторной карты пациента с использованием
данных национального ЭПЗ. Данный процесс включает, как
минимум:
R2.4.1.1
M Просмотр списка пациентов, записавшихся на прием
R2.4.1.2
M Создание и редактирование шаблонов в том числе формирование
медицинских документов и записей, консультаций, протоколов
осмотров, дневниковых записей с помощью шаблонов и
возможностью прикрепления файлов (изображений, видеозаписи,
звукозаписи) с привязкой пользовательских шаблонов к учетной
записи
R2.4.1.3
M Создание медицинских записей на основе стандартных или
пользовательских шаблонов
R2.4.1.4
M Редактирование и удаление медицинских записей, находящихся в
неподписанном виде
Раздел VI. Технические требования
153
R2.4.1.5
M Вывод на печать заполненных медицинских записей для
формирования бумажной версии амбулаторной карты
R2.4.1.6
M Возможность выборки медицинских записей по определенному
признаку (посещения, диагнозы, даты, диагностические
исследования, лабораторные анализы, услуги, источники
финансирования и т.д.)
R2.4.1.7
M Отчет об изменении числовых показателей пациента во времени
(антропометрические показатели, функциональные показатели,
лабораторные данные и т.д.)
R2.4.2
M Создание направлений на внутренние (в пределах данной
медицинской организации) и внешние (в другие медицинские
организации) КДУ. Данный процесс включает, как минимум:
R2.4.2.1
M Создание направления на дополнительные КДУ в рамках
направления из подразделения ПСМП внутри организации с
возможностью записи на определенное время
R2.4.2.2
M Добавление дополнительных КДУ без согласования с
подразделением ПМСП
R2.4.2.3
M Создание заявки на дополнительные виды исследований для
согласования с подразделением ПМСП
R2.4.2.4
M Отметка о выполнении КДУ
R2.4.2.5
M Формирование протокола консультации, осмотра, операции на
основании стандартных и пользовательских шаблонов
R2.4.2.6
M Формирование рекомендаций по подготовке к КДУ на основе
стандартных шаблонов
R2.4.2.7
M Удаление направлений (некорректных, по инициативе пациента,
автоматическое при неявке пациента)
R2.4.2.8
M Контроль за исполнением КДУ. Регистрация впервые выявленного
диспансерного больного и передача сведений для участкового врача,
рекомендации по периодичности наблюдения и обследования
R2.4.2.9
M Формирование отчетных форм:
1. Отчет о созданных направлениях (внутренние, внешние) по
услугам, источникам финансирования
2. Пофамильный список направленных на консультативнодиагностическую помощь
Раздел VI. Технические требования
154
3. Отчет о выполненных КДУ
4. Пофамильный список пациентов, получивших КДУ
R2.4.3
M Формирование врачебных назначений лекарственных средств и/или
процедур и манипуляций. Данный процесс включает, как минимум:
R2.4.3.1
M Создание рецептов на лекарственные средства (платные,
бесплатные) с описанием способов приема, дозировок и т.д.
R2.4.3.2
M Контроль назначений в соответствии с установленными
максимальными разовыми дозами в зависимости от возраста, пола,
веса и т.д.
R2.4.3.3
M Контроль назначений в соответствии с формуляром Организации и
Республики Казахстан
R2.4.3.4
M Подписание рецептов с помощью ЭЦП
R2.4.3.5
M Проверка наличия лекарственного препарата в аптеке
R2.4.3.6
M Создание направлений на выполнение процедур
R2.4.3.7
M Формирование рекомендаций по подготовке к процедурам на основе
стандартных шаблонов.
R2.4.3.8
M Контроль за выполнением назначений и отпуском лекарственных
препаратов
R2.4.3.9
M
Предоставление рекомендуемых назначений согласно утвержденных
клинических руководств и протоколов диагностики и лечения
R2.4.3.10
M
Формирование отчетных форм:
1. Отчет о созданных рецептах (МНН, форма, дозировка, способ
приема и т.д.)
2. Пофамильный список назначенных и получивших рецепты
3. Пофамильный список назначенных и получивших льготные
рецепты
4. Пофамильный список назначенных и получивших ИМН
5. Пофамильный список направленных на консультативнодиагностическую помощь
6. Отчет о направлениях на процедуры (открытые,
выполняющиеся, выполненные, откроленные, внешние,
Раздел VI. Технические требования
155
внутренние)
R2.4.4
M Ведение первичной учетной документации на уровне профильного
специалиста в соответствии с действующими нормативными
правовыми актами РК. Данный процесс включает, как минимум
ведение следующих учетных форм:
R2.4.5
M 001-3/у, 001-4/у, 001-5/у, 001-6/у, 007-1/у, 025/у, 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/у, 098/у, 111/у,
112/у, 128/у, 130/у, 132/у, 133/у, 138/у, 278/у,
R2.4.6
M Ведение учета листов временной нетрудоспособности. Данный
процесс включает, как минимум:
R2.4.7
M Регистрация листа временной нетрудоспособности
R2.4.7.1
M Продление листа временной нетрудоспособности
R2.4.7.2
M Закрытие листа временной нетрудоспособности
R2.4.7.3
M Отправка листа временной нетрудоспособности на согласование с
заведующим отделением или с ВКК.
R2.4.7.4
M Формирование
отчета
нетрудоспособности
R2.4.7.5
M Формирование направления на медицинскую социально-экспертную
коммисию (МСЭК), создание и редактирование шаблонов для МСЭК
R2.4.8
M Формирование аналитических форм на уровне профильного
специалиста, а также статистических таблиц в соответствии с
действующими нормативными правовыми актами РК. Данный
процесс включает, как минимум:
R2.4.8.1
M
о
выданных
листах
временной
1. Ведомость учета посещений в поликлинике (амбулатории),
диспансере, консультации и на дому (039/у)
2. Отчет о выполнении скрининговых обследований согласно
приказа МЗ РК № 685от 10 ноября 2009 года
Раздел VI. Технические требования
156
3. Отчет о движении диспансерных больных
4. Отчет об инвалидности
5. Отчет о взрослой инвалидности
6. Отчет о плановой госпитализации
7. Отчет о числе заболеваний, зарегистрированнных у больных,
проживающих в районе обслуживания медицинской
организации и контингентах больных, состоящих под
диспансерным наблюдением (форма 56, 12)
8. Отчет о контингентах больных, получивших
стационарозамещающую помощь (форма 24)
9. Отчет о медицинской помощи детям (форма 31)
10. Отчет по детской инвалидности (форма 52)
11. Отчет об использовании коечного фонда медицинских
организаций, оказывающих стационарную и
стационарозамещающую помощь (форма 21)
Модуль «5. Заведующий отделением поликлиники»
R2.5
R2.5.1
М Подтверждение или отклонение направлений на отдельные виды
услуг с использованием ЭЦП.
R2.5.2
М Ведение и согласование первичной учетной документации на уровне
заведующего отделением в соответствии с действующими
нормативными правовыми актами РК. Данный процесс включает,
как минимум ведение следующих учетных форм:
R2.5.2.1
M
1. 035/у
2. 035-1/у
3. 035-2/у
4. 035-3/у
5. 095/у
6. 094/у
R2.5.3
М Формирование аналитических форм на уровне заведующего
отделением, а также статистических таблиц в соответствии с
действующими нормативными правовыми актами РК. Данный
процесс включает, как минимум:
R.2.6.3.1
M Формирование отчетных форм:
1. Формирование аналитических форм в разрезах аналогичных
таблицам сотрудников отделения
Раздел VI. Технические требования
157
2. Отчет о прикрепленном населении по участкам
3. Отчет о половозрастной структуре прикрепленного населения
4. Отчет о кадровом составе участковой службы
5. Отчет по основным индикаторам деятельности участков
6. Форма 12
7. Отчет по структуре посещений (в разрезе заболевании,
профилактических скринингов, диспансерных больных, по
визитам на приеме, на дому, оказания СЗТ, визиты к среднему
медицинскому персоналу, в доврачебный кабинет, процедурный
кабинет, на профпрививки)
8. Отчет по госпитализациям жителей прикрепленного
населения
9. Структура консультативных приемов по профильным
специалистам в разрезе участков прикрепленного населения
R2.5.4
М Согласование листа временной нетрудоспособности, ведение
записей ВКК. Данный процесс включает, как минимум :
R2.5.4.1
M Согласование длительных листов нетрудоспособности
R2.5.4.2
M Создание записей заседаний ВКК
R2.5.4.3
M Формирование заключений ВКК
R2.5.4.4
M Подпись заключений ВКК с помощью ЭЦП
R2.5.4.5
M Формирование отчетных форм:
1. Отчет о выданных листах временной нетрудоспособности
2. Отчет о количестве лиц прошедших через ВКК
3. Отчет о числе лиц направленных на переосвидетельствование в
МСЭ
R2.6
Модуль «6. Медицинская статистика поликлиники»
R2.6.1
M Мониторинг ведения первичной учетной документации в
Организации
R2.6.2
M Формирование аналитических форм на уровне специалиста по
медицинской статистике, а также статистических таблиц в
соответствии с действующими нормативными правовыми актами РК.
Данный процесс включает, как минимум:
Раздел VI. Технические требования
158
R2.6.2.1
M Конструктор отчетных форм с возможностью создания новых
отчетных форм и редактирования имеющихся
R2.6.2.2
M Формирование отчетных форм:
1. Форма 039/у
2. Форма 007/у
3. Отчет о прикрепленном населении и его половозрастной
структуре
4. Отчет о выполнении скрининговых обследований
5. Отчет о кадровом составе участков
6. Отчет о работах по прикреплению населения
7. Отчетные формы 21, 12, 17, 24, 30, 31, 32, 43, 47, 52, 59, 4, 5,
6, 56, 58
R2.7
Модуль «7. Приемный покой»
R2.7.1
М Регистрация обращений пациентов. Данный процесс включает, как
минимум:
R2.7.1.1
M Уточнение демографических данных пациента
R2.7.1.2
M Проверка и ввод данных о категории страховки и оплаты пациента
R2.7.1.3
M Регистрация медицинского направления и/или отказа в оказании
медицинской помощи
R2.7.1.4
M Оформление и выдача медицинских документов
R2.7.1.5
M Установление связи между дублями направлений
R2.7.1.6
M Распределение пациентов по специализированным отделениям и
палатам
R2.7.1.7
M Предварительное прикрепление пациента к лечащему врачу
R2.7.1.8
M Подтверждение готовности принять больного
R2.7.2
M Ведение ЭМЗ пациента. Данный процесс включает, как минимум:
R2.7.2.1
M Полное описание процессов и требований ведения ЭМЗ выполняется
в соответствии с национальным стандартом Электронной
медицинской записи. (Утвержденный Приказом и.о. Министра
Раздел VI. Технические требования
159
здравоохранения №75 от 10.02.2014 г «Об утверждении технической
документации по вопросам электронного здравоохранения»)
R2.7.2.2
M Из тех данных, которые введены в ЭМЗ, минимальный обязательный
набор данных передается в национальный ЭПЗ в соответствии с
национальным стандартом Электронного паспорта здоровья
R2.7.3
M Уточнение услуг, выполненных до госпитализации. Данный процесс
включает, как минимум:
R2.7.3.1
M Просмотр ЭПЗ пациента из национального Репозитория ЭПЗ
R2.7.3.2
M Регистрация диагнозов, процедур, назначений и других данных о
медицинских услугах, выполненных до госпитализации, но не
введенных в системе
R2.7.4
M Ведение первичной учетной документации таблиц на уровне
приемного покоя. Данный процесс включает, как минимум ведение
следующих учетных форм:
R2.7.4.1
M 001/у, 003/у, 004-1/у, 045/у, 058/у, 060/у, 069/у, 264/у
R2.7.5
M Формирование аналитических форм на уровне приемного покоя.
Данный процесс включает, как минимум:
R2.7.5.1
M Формирование отчетных форм:
1.
Отчет о количестве проведенных услуг, манипуляций,
обследований
2.
Отчет по медикаментам и вакцинам
3.
Отчет о проделанной работе (кол-во обратившихся больных,
количество госпитализированных в круглосуточный стационар в
плановом и экстренном порядке, в дневной стационар, количество
отказов от госпитализации, кол-во доставленных по скорой помощи,
направлено из ПМСП или самообращение)
4.
Отчет об активах, переданных в поликлинику
Формирование таблицы сети коечного фонда МО с указанием
свободных
5.
R2.7.6
M Взаимодействие с ИС МЗСР РК. Данный процесс включает, как
минимум:
R2.7.6.1
M Обмен информацией об услугах оказанных в приемном покое до
госпитализации
R2.7.6.2
M Обмен информацией о госпитализации и отказах госпитализации
Раздел VI. Технические требования
160
R2.7.6.3
M Обмен информацией о состоянии коечного фонда
R2.7.6.4
M Обмен данными с ИС МЗСР РК в соответствии с требованиями
интероперабельности МЗСР РК
R2.8
Модуль «8. Врач стационара»
R2.8.1
М Ведение ЭМЗ пациента. Данный процесс включает, как минимум:
R2.8.1.1
M Полное описание процессов и требований ведения ЭМЗ выполняется
в соответствии с национальным стандартом Электронной
медицинской записи. (Утвержденный Приказом и.о. Министра
здравоохранения №75 от 10.02.2014 г «Об утверждении технической
документации по вопросам электронного здравоохранения»)
R2.8.1.2
M Из тех данных, которые введены в ЭМЗ, минимальный обязательный
набор данных передается в национальный ЭПЗ в соответствии с
национальным стандартом Электронного паспорта здоровья
R2.8.1.3
M Формирование истории болезни, на основе стандартного шаблона
для соответствующего коечного фонда (персональные данные,
анамнез заболевания, анамнез жизни, перенесенные заболевания,
результаты первичного осмотра, назначения)
R2.8.1.4
M Составление предварительного плана лечения и при необходимости
дополнительных исследований
R2.8.1.5
M Регистрация ежедневных осмотров и результатов обследований
больного лечащим врачом
R2.8.2
M Ведение направлений на КДУ. Данный процесс включает, как
минимум:
R2.8.2.1
M Уточнение плана лечения, использование плана во время лечения
пациента, изменение плана при необходимости.
R2.8.2.2
M Формирование направлений на лабораторные исследования,
изучение результатов и (при необходимости) написание
интерпретаций
R2.8.2.3
M Формирование направлений на диагностические исследования,
изучение результатов и написание интерпретаций
R2.8.2.4
M Формирование направлений на консультации к другим врачамспециалистам, изучение заключений специалистов
R2.8.2.5
M Мониторинг состояния направлений и определение опозданий и
Раздел VI. Технические требования
161
отказов
R2.8.3
M Постановка диагноза. Данный процесс включает, как минимум:
R2.8.3.1
M Просмотр истории болезни из национального ЭПЗ
R2.8.3.2
M Просмотр результатов анализов
R2.8.3.3
M Уточнение и регистрация диагнозов: диагноз направившей
организации (направительный), диагноз при поступлении
(предварительный), заключительный клинический диагноз,
осложнения, сопутствующие заболевания, окончательный,
патологоанатомический диагноз
R2.8.3.4
M Мониторинг выполнения плана лечения и его уточнение
R2.8.4
M Формирование врачебных назначений лекарственных средств и/или
процедур и манипуляций. Данный процесс включает, как минимум:
R2.8.4.1
M Данные аллергического анамнеза пациента
R2.8.4.2
M Проверка совместимости лекарств
R2.8.4.3
M Формирование назначений больным по приему лекарств
R2.8.4.4
M Назначение лечебных и диагностических процедур
R2.8.4.5
M Мониторинг правильности и своевременности выполнения
назначений со стороны медицинской сестры и вовлеченных
участников лечения
R2.8.4.6
M Регистрация фактов побочного действия и осложнений лекарств и
процедур
R2.8.5
M Выписка пациента. Данный процесс включает, как минимум:
R2.8.5.1
M Определение окончательного диагноза
R2.8.5.2
M Составление формы 066/у
R2.8.5.3
M Составление выписного эпикриза
R2.8.5.4
M Регистрация факта освобождения койко-места
Раздел VI. Технические требования
162
R2.8.6
M Формирование аналитических форм на уровне врача. Данный
процесс включает, как минимум:
R2.8.6.1
M Формирование отчетных форм:
1.
Отчет о проделанной работе (количество пролеченных
больных с исходами)
2.
Отчет о количестве проведенных операций (в том числе с
осложнениями)
3.
Отчет о количестве проведенных манипуляций
Отчет о деятельности коечного фонда (работа койки, СДПБ,
выполнение койко дней, летальность)
4.
5.
Отчет об использовании диагностических исследований
6.
Отчет о реабилитационных процедурах
R2.8.6.2
M Формирование аналитических форм
R2.8.7
M Ведение первичной учетной документации на уровне врача
стационара. Данный процесс включает, как минимум ведение
следующих учетных форм:
R2.8.7.1
M 003/у, 004-1/у, 005/у, 008/у, 011/у, 011-2/у, 011-3/у,027/у, 066/у, 0664/у
R2.9
Модуль «9. Медсестра стационара»
R2.9.1
M Ведение ЭМЗ пациента. Данный процесс включает, как минимум:
R2.9.1.1
M Полное описание процессов и требований ведения ЭМЗ выполняется
в соответствии с национальным стандартом Электронной
медицинской записи. (Утвержденный Приказом и.о. Министра
здравоохранения №75 от 10.02.2014 г «Об утверждении технической
документации по вопросам электронного здравоохранения»)
R2.9.1.2
M Из тех данных, которые введены в ЭМЗ, минимальный обязательный
набор данных передается в национальный ЭПЗ в соответствии с
национальным стандартом Электронного паспорта здоровья
(Утвержденный Приказом и.о. Министра здравоохранения №75 от
10.02.2014 г «Об утверждении технической документации по
вопросам электронного здравоохранения»)
R2.9.1.3
M Уточнение демографических данных о пациенте
R2.9.1.4
M Функционал ведения плана лечения
Раздел VI. Технические требования
163
R2.9.1.5
M Регистрация нужных направлений (запись на прием) в лабораторные,
диагностические кабинеты и к другим специалистам в соответствии
с направлениями и назначениями врача
R2.9.1.6
M Формирование отчетных форм:
1. Отчет по медикаментам и ИМН
2.
Отчет о проведенных процедурах
3.
Отчет перевязочного кабинета
R2.9.2
M Отметка о выполнении назначений и лечения. Данный процесс
включает, как минимум:
R2.9.2.1
M Отметка о лекарствах принятых пациентом
R2.9.2.2
M Отметка о проведенных процедурах (для исключительных случаев,
когда процедурный кабинет не имеет рабочих мест для регистрации
процедур)
R2.9.2.3
M Отметка о перенесенных операциях (для случаев, когда
операционная не имеет рабочих мест для регистрации проведенных
операций)
R2.9.2.4
M Ввод результатов лабораторных анализов и диагностических тестов
(в случае если у соответствующих кабинетов нет рабочих мест для
регистрации результатов)
R2.9.3
M Мониторинг состояния больного. Данный процесс включает, как
минимум:
R2.9.3.1
M Отметка о проведенной оценке состояния больного (температура,
жалобы, и т.п)
R2.9.3.2
M Мониторинг реализации плана лечения
R2.9.3.3
M Оповещение в случае экстренных ситуаций
R2.9.4
M Ведение первичной учетной документации на уровне медицинской
сестры. Данный процесс включает, как минимум:
R2.9.4.1
M Вывод на печать направлений и плана лечения
R2.9.4.2
M
Система должна быть способной вести следующие учетные формы:
1.
004/у, 004-1/у, 007/у, 009/у, 029/у,
Раздел VI. Технические требования
2.
Журнал забора крови на ВИЧ
3.
Журнал передачи реципиентов в поликлинику
4.
Журнал учета медикаментов
5.
Журнал учета перевязочного материала
6.
Требование в аптеку
7.
Журнал учета и списания спирта
164
8.
Журнал учета наркотических средств, психотропных веществ
и прекурсоров (ПП РК № 396 от 30.03.2012г)
R2.9.5
M Формирование аналитических форм на уровне среднего
медицинского персонала. Данный процесс включает, как минимум:
R2.9.5.1
М Формирование отчетных форм:
1.
Отчет об использованных медикаментах, в том числе
наркотическим веществам и спирту
2.
Отчет об использованных ИМН
3.
Отчет по определению группы крови
4.
Отчет о выявленных инфекционных больных
5.
Отчет по переливанию крови и кровезаменителей
Отчет по забору крови и других средств организма для
исследования
6.
R2.10
7.
Отчет по забору биопсийного материала
8.
Отчет по направлениям на внешние исследования
Модуль «10. Питание»
R2.10.1
M Формирование ежедневного меню. Данный процесс включает, как
минимум:
R2.10.1.1
M Формирование меню-требования, редактирование, защита от
редактирования после утверждения
R2.10.1.2
M Формирование меню-раскладок с указанием блюд, редактирование ,
защита от редактирования после утверждения
R2.10.1.3
M Просмотр списка блюд для каждого типа диеты (Стола)
R2.10.1.4
M Просмотр списка больных отсортированных по диетам, палатам,
отделениям, и т.д.
Раздел VI. Технические требования
165
R2.10.1.5
M Просмотр отзывов больных и специалистов о качестве питания
R2.10.2
M Калькулятор ежедневного, ежемесячного расхода продуктов на
меню. Данный процесс включает, как минимум:
R2.10.2.1
M Расчет необходимых продуктов на конкретный день, с учетом
списочного состава больных по всей медицинской организации
R2.10.2.2
M Корректировка количества необходимых порций (с обязательным
логированием изменений) каждого типа диет
R2.10.2.3
M Автоматический расчет количества и состава необходимых
продуктов.
R2.10.2.4
M Вывод на печать заказа на поставку продуктов
R2.10.2.5
M Просмотр всех вышеназванных данных для предыдущих периодов
(при этом корректировка данных за предыдущие периоды возможно
только специальным разрешением главного врача, которое выдается
на ограниченный срок)
R2.10.2.6
M Возможность просмотра журнала логирования для случаев ручных
изменений количества порций
R2.10.3
M Расчет пищевой ценности блюд в рационе. Данный процесс
включает, как минимум:
R2.10.3.1
M Расчет ценности блюд с учетом норм отходов и потерь при
различных видах кулинарной обработки
R2.10.3.2
M Автоматические подсказки по составу и пищевой ценности для
различных диет
R2.10.3.3
M Отчет о пищевой ценности по каждой диете и приведением
рекомендованных стандартов по каждой диете
R2.10.4
M Формирование справочников пищевых продуктов, Данный процесс
включает, как минимум:
R2.10.4.1
M Справочник основных пищевых продуктов и полуфабрикатов,
R2.10.4.2
M Справочник карточек и состава блюд
R2.10.4.3
M Справочник блюд диетического питания (Столы 1-15)
R2.10.5
M Управление диетой пациентов
Раздел VI. Технические требования
166
R2.10.5.1
M Просмотр рекомендаций о диетах от специалистов и лечащих врачей
для каждого больного
R2.10.5.2
M Назначение диеты (номер стола) больным
R2.10.5.3
M Изменение диеты
R2.10.5.4
M Просмотр отзывов пациентов и врачей о качестве питания
R2.10.6
M Формирование аналитических форм по питанию.
R2.11
Модуль «11. Дневной стационар»
R2.11.1
M Ведение ЭМЗ пациента . Данный процесс включает, как минимум:
R2.11.1.1
M Полное описание процессов и требований ведения ЭМЗ выполняется
в соответствии с национальным стандартом Электронной
медицинской записи. (Утвержденный Приказом и.о. Министра
здравоохранения №75 от 10.02.2014 г «Об утверждении технической
документации по вопросам электронного здравоохранения»)
R2.11.1.2
M Из тех данных, которые введены в ЭМЗ, минимальный обязательный
набор данных передается в национальный ЭПЗ в соответствии с
национальным стандартом Электронного паспорта здоровья
(Утвержденный Приказом и.о. Министра здравоохранения №75 от
10.02.2014 г «Об утверждении технической документации по
вопросам электронного здравоохранения»)
R2.11.1.3
M Формирование истории болезни
R2.11.1.4
M Составление предварительного плана лечения и дополнительных
исследований
R2.11.1.5
M Регистрация визитов и обследования больного лечащим врачом
R2.11.2
M Создание направлений на консультативно-диагностические услуги.
Данный процесс включает, как минимум:
R2.11.2.1
M Уточнение плана лечения, использование плана во время лечения
пациента, изменение плана при необходимости.
R2.11.2.2
M Формирование направлений на лабораторные анализы, изучение
результатов и (при необходимости) написание интерпретаций
R2.11.2.3
M Формирование направлений на диагностические исследования,
изучение результатов и написание интерпретаций
Раздел VI. Технические требования
167
R2.11.2.4
M Формирование направлений на консультации к другим врачамспециалистам, изучение заключений специалистов
R2.11.2.5
M Мониторинг состояния направлений и определение опозданий и
отказов
R2.11.3
M Регистрация врачебных назначений и их выполнения. Данный
процесс включает, как минимум:
R2.11.3.1
M Изучение аллергического анамнеза
R2.11.3.2
M Проверка совместимости лекарств
R2.11.3.3
M Формирование назначений больным по приему лекарств
R2.11.3.4
M Назначение процедур
R2.11.3.5
M Отметка о факте выполнения процедур
R2.11.3.6
M Мониторинг правильности и своевременности выполнения
назначений со стороны медицинской сестры и вовлеченных
участников лечения
R2.11.3.7
M Регистрация фактов побочных действий и осложнений лекарств и
процедур
R2.11.4
M Ведение первичной учетной документации на уровне дневного
стационара в соответствии с действующими нормативными
правовыми актами РК. Данный процесс включает, как минимум:
R2.11.4.1
M
R2.11.5
M Формирование аналитических форм на уровне дневного стационара,
а также статистических таблиц в соответствии с действующими
нормативными правовыми актами РК. Данный процесс включает,
как минимум:
R2.11.5.1
M Формирование отчетных форм:
001-3/у, 001-4/у, 003-2/у, 004-1/у, 027/у, 029/у, 066-4/у
1.
Отчет о проделанной работе (количество пролеченных
больных с исходами)
2.
Отчет о количестве проведенных операций (в том числе
осложнения)
3.
Отчет о количестве проведенных процедур и манипуляций
4.
Счет –реестр за отчетный период с указанием стоимости
Раздел VI. Технические требования
168
лечения по нозологическим формам
5.
Отчет о средней длительности пребывания
R2.11.6
M Взаимодействие с ИС МЗСР РК. Данный процесс включает как
минимум:
R2.11.6.1
M Обмен информацией о пролеченных случаях
R2.11.6.2
M Обмен клинической информацией (диагнозы, результаты
консультаций и осмотров и т.д.)
R2.11.6.3
M Обмен информацией о направлениях
R2.11.6.4
M Обмен информацией о рецептах
Модуль «12. Заведующий отделением стационара»
R2.12
R2.12.1
M Подтверждение или отклонение направлений на отдельные виды
услуг с использованием ЭЦП.
R2.12.2
M Ведение и согласование первичной учетной документации на уровне
заведующего отделением в соответствии с действующими
нормативными правовыми актами РК.
R2.12.2.1
M
Система должна быть способной регистрировать информацию
следующих первичных учетных форм:
035/у, 035-1/у, 035-2/у, 035-3/у, 094/у, 095/у
R2.12.3
M Формирование аналитических форм на уровне заведующего
отделением, а также статистических таблиц в соответствии с
действующими нормативными правовыми актами РК в форме и
разрезах аналогичных таблицам сотрудников отделения. Перечень
аналитических и статистических форм должен быть согласован с
Заказчиком на этапе проектирования Системы.
R2.12.4
M Согласование больничного листа, ведение записей консилиума.
Данный процесс включает, как минимум:
R2.12.4.1
M Согласование длительных листов нетрудоспособности
R2.12.4.2
M Создание записей заседаний консилиума
R2.12.4.3
M Формирование заключений консилиума
Раздел VI. Технические требования
R2.12.4.4
M Подпись заключений консилиума с помощью ЭЦП
R2.12.4.5
M Формирование отчетных форм:
169
1. Отчет о выданных листах временной нетрудоспособности
2. Отчет о лицах прошедших через консилиум
3. Отчет о показателях работы коечного фонда отделения
4. Отчет о пролеченных пациентах
5. Структура пролеченных случаев по нозологическим группам и
возрастам
6. Отчет по оказанным услугам по кодам тарификатора
R2.13
Модуль «13. Главный врач»
R2.13.1
M Формирование аналитических форм на уровне главного врача, а
также статистических таблиц в соответствии с действующими
нормативными правовыми актами РК. Перечень аналитических и
статистических форм должен быть согласован с Заказчиком на этапе
проектирования Системы.Данный процесс включает, как минимум:
R2.13.1.1
M Контроль и управление ведения первичной учетной документации в
МО
R2.13.1.2
M Аналитические формы и отчетные формы доступные всем
подразделениям Организации с разделением по подразделениям.
R2.14
Модуль «14 Медицинская статистика стационара»
R2.14.1
M Ведение коечного фонда. Данный процесс включает, как минимум:
R2.14.1.1
M Ведение справочника коечного фонда в разрезе подразделений,
палат, коек
R2.14.1.2
M Настройка использования коечного фонда (разворачивание коек,
сворачивание коек, разворачивание и сворачивание временных коек,
установление максимального числа коек в палате, ведение
информации по профилям коек, перепрофилированию коек,
закрытию и сокращению коек)
R2.14.1.3
M Ввод дополнительной информации о койке, палате (мужская,
женская)
R2.14.2
M Формирование аналитических форм на уровне кабинета
Раздел VI. Технические требования
170
медицинской статистики, а также статистических таблиц в
соответствии с действующими нормативными правовыми актами РК.
R2.14.2.1
M Формирование первичных форм и отчетных форм:
1.
Ежедневных :007/у, 007-1/у,
2.
Ежемесячных: 016/у
3.
Форма 21
4.
Форма 14 годовая (МКБ-10 и МКБ-9)
5.
Форма 32 годовая
6.
Форма 30 годовая
7.
перечень пролеченных случаев ВСМП с указанием операций;
8.
отчет о деятельности стационара;
9.
работа отделений в разрезе профилей коек;
10.
состав больных, сроки и исходы;
11.
основные показатели деятельности стационара;
12.
сведения о структуре всех видов стационарной помощи;
13.
состав больных по группам диагнозов;
14.
состав пролеченных больных по исходам;
15.
статистические данные о работе ординаторов;
16.
хирургическая работа по отделениям;
17.
анализ деятельности хирургической службы;
18.
свод по оперированным в разрезе профилей коек;
19.
сведения о дооперационном пребывании;
20.
операции по хирургическим отделениям;
21.
состав больных по хирургическим отделениям;
22.
анализ деятельности реанимационного отделения;
23.
анализ летальности и совпадения
патологоанатомического диагнозов;
24.
анализ
диагнозов;
совпадения направительного и
клинического
и
заключительного
25.
данные о пролеченных по районам и областям;
26.
данные о пролеченных по направлениям «БГ»;
27.
данные по типам травм;
Раздел VI. Технические требования
171
28.
данные о поступивших в алкогольном опьянении;
29.
список пролеченных больных;
30.
список б-х находящихся в стационаре;
31.
список умерших для предоставления в РАГС;
32.
список умерших в стационаре в разрезе районов;
33.
список умерших по половозрастной структуре;
34.
информация по пролеченным сельским жителям;
35.
список оперированных б-х по отделениям;
36.
список оперированных больных врачами отделений;
37.
список больных по выбранным диагнозам;
38.
список больных с осложнениями после операции;
39.
список больных прошедших через реанимацию;
40.
список больных переведенных в др.стационар
41.
список пролеченных, оказавшихся здоровыми;
42.
список больных имеющих льготную категорию;
43.
список больных поступивших повторно в течении месяца;
44.
половозрастной состав пролеченных по профилям;
45.
отчет по услугам диагностических отделений;
46.
структура больных БСК в разрезе нозологии, возрастов и
исходов;
47.
отчет по пролеченным случаям в разрезе КЗГ.
R2.14.2.2
M Мониторинг ведения первичной учетной документации в
Организации
R2.14.2.3
M Конструктор отчетных форм с возможностью создания новых
отчетных форм и редактирования имеющихся
R2.15
Модуль «15. Процедуры и манипуляции»
R2.15.1
M Ведение ЭМЗ пациента. Данный процесс включает, как минимум:
R2.15.1.1
M Полное описание процессов и требований ведения ЭМЗ выполняется
в соответствии с национальным стандартом Электронной
медицинской записи. (Утвержденный Приказом и.о. Министра
здравоохранения №75 от 10.02.2014 г «Об утверждении технической
документации по вопросам электронного здравоохранения»)
Раздел VI. Технические требования
172
R2.15.1.2
M Из тех данных, которые введены в ЭМЗ, минимальный обязательный
набор данных передается в национальный ЭПЗ в соответствии с
национальным стандартом Электронного паспорта здоровья
(Утвержденный тем же приказом)
R2.15.1.3
M Идентификация пациента
R2.15.1.4
M Отметка о выполнении назначенных процедур
R2.15.1.5
M Запись пациента на определенное время при необходимости
повторного получения услуги
R2.15.2
M Ведение первичной учетной документации по оказанным
процедурам и манипуляциям в соответствии с действующими
нормативными правовыми актами РК . Данный процесс включает,
как минимум:
R2.15.2.1
M
R2.15.3
M Формирование аналитических форм по оказанным процедурам и
манипуляциям, а также статистических таблиц в соответствии с
действующими нормативными правовыми актами РК. Данный
процесс включает, как минимум:
R2.15.3.1
M Формирование отчетных форм:
Отчет о выполненных услугах (по аппаратам, исполнителям,
источникам финансирования, видам услуг)
R2.16
029/у, 042/у,044/у, 046/у, 047/у, 058/у, 063/у, 064/у, 064-1/у, 064-2/у,
069/у, 150/у
Модуль «16. Администратор»
R2.16.1
M Управление базой данных. Данный процесс включает, как минимум:
R2.16.1.1
M Мониторинг и оптимизация производительности БД
R2.16.1.2
M Управление базой данных: настройка хранилища, расширение базы
данных
R2.16.1.3
M Управление пользователями и паролями БД
R2.16.1.4
M Управление правами доступа БД в соответствии с Приложением 1
R2.16.1.5
M Архивация данных за определенный период времени о пациентах
R2.16.1.6
M Восстановление данных из архивов на отдельных серверах для
поиска старых данных.
Раздел VI. Технические требования
173
R2.16.2
M Создание групп пользователей и отдельных пользователей Системы.
Данный процесс включает, как минимум:
R2.16.2.1
M Создание, удаление и редактирование учетных записей
пользователей;
R2.16.2.2
M Создание, удаление и редактирование ролей пользователей;
R2.16.2.3
M Прикрепление ролей конкретным пользователям (один и тот же
пользователь может иметь несколько ролей)
R2.16.2.4
M Добавление, изменение и удаление прав доступа ролей к модулям,
первоначальные права должны быть присвоены в соответствии с
Приложением 1.
R2.16.2.5
M Временный запрета доступа пользователя в систему
R2.16.3
M Управление типами аутентификации (парольная, ЭЦП). Данный
процесс включает, как минимум:
R2.16.3.1
M Создание первоначальных паролей
R2.16.3.2
M Изменение паролей для тех пользователей, которые сами не в
состоянии их менять
R2.16.3.3
M Изменение политик управления паролями
R2.16.3.4
M Использование внешних ключей
R2.16.3.5
M Просмотр попыток доступа с невалидными ключами
R2.16.4
M Ведение системных журналов. Данный процесс включает, как
минимум:
R2.16.4.1
M Журнал создания, изменения и удаления записей в базе данных
R2.16.4.2
M Журнал истории входов пользователей
R2.16.4.3
M Журнал получения отчетных форм
R2.16.4.4
M Журнал просмотра данных
R2.16.4.5
M Журнал действий по архивированию
Раздел VI. Технические требования
174
R2.16.4.6
M Журнал ошибок и аварийных остановок программы
R2.16.4.7
M Журнал синхронизации с внешними (национальными)
справочниками, классификаторами, индексами и регистрами
R2.16.5
M Настройка шаблонов медицинской документации. Данный процесс
включает, как минимум:
R2.16.5.1
M Создание новых шаблонов
R2.16.5.2
M Изменение (создание новых версий) существующих шаблонов
R2.16.5.3
M Прикрепление шаблонов к модулям и пользователям и их
открепление
R2.16.5.4
M Использование при создании и редактировании шаблонов
следующих функций:
 изменение настроек шрифта (стиль, размер, жирный,
подчеркнутый, курсив и т.д.)
 изменение цвета шрифта
 создание сложных шаблонов с подразделами
 возможность использования любого справочника в системе
для заполнения поля в шаблоне
 возможность использования любой сущности в базе данных
для заполнения поля в шаблоне
 возможность использования любой выборки из базы данных
для заполнения поля в шаблоне
 формирование правил заполнения шаблона: только из списка,
из списка с возможностью дополнения, в свободной форме, из
выборки и т.д.
 создание новых справочников, используемых при заполнении
шаблона
R2.16.6
M Настройка пользовательского интерфейса. Данный процесс
включает, как минимум:
R2.16.6.1
M Управление доступом к инструментам интерфейса в зависимости от
прав доступа пользователей
R2.16.6.2
M Возможность изменения стиля (например: цветовой гаммы, размера
полей, шрифтов)
Раздел VI. Технические требования
175
R2.16.6.3
M Возможность создания индивидуальных шаблонов для каждого
пользователя, включая присвоение значений по умолчанию
отдельным полям в шаблонах данного пользователя.
R2.16.7
M Настройка доступа пользователей. Данный процесс включает, как
минимум:
R2.16.7.1
M Добавление, изменение и удаление прав пользователей на действия в
Системе
R2.16.7.2
M Управление (добавление, изменение и удаление) доступом к данным
в разрезе организационной структуры предприятия: в пределах
структурного подразделения закрепленного за пользователем, в
пределах всей медицинской организации в соответствии с
организационной структурой предприятия
R2.16.7.3
M Закрепление за пользователем прав на просмотр, создание,
изменение, удаление данных по конкретным структурным
подразделениям
R2.16.7.4
M Добавление, изменение и удаление доступа пользователей к отчетам
R2.16.7.5
M Управление временем – графиком работы работников, в течении
которого пользователь имеет право доступа к Системе
R2.16.7.6
M Управление доступом к данным пациентов в соответствии с
политикой конфиденциальности персональных данных МЗСР РК.
R2.16.7.7
M Установка признака конфиденциальности для тех персональных
данных, которые должны храниться в базе данных в зашифрованной
форме
R2.16.7.8
M Просмотр журналов (логов) с действиями конкретных пользователей
за определенный период времени
R2.16.7.9
M Архивация и очистка журнала логирования с данными о действиях
пользователей за определенный период в соответствии с политиками
МЗСР РК
R2.16.7.10
M Просмотра архивов логов
R2.16.8
M Настройка подключения внешних программ. Данный процесс
включает, как минимум:
R2.16.8.1
M Разрешение доступа определенных IP-адресов
R2.16.8.2
M Разрешение определенных программ и сервисов
Раздел VI. Технические требования
176
R2.16.8.3
M Изменение паролей доступа внешних программ
R2.16.9
M Управление справочниками. Данный процесс включает, как
минимум:
R2.16.9.1
M Изменение содержания (дополнение, редактирование) локальных
справочников системы
R2.16.9.2
M Мониторинг процесса синхронизации внешних (национальных)
справочников, индексов и регистров
R2.16.9.3
M Мониторинг правильности (или возможных проблем) обмена
данными с внешними источниками данных (национальный ЭПЗ,
национальное аналитическое хранилище)
R2.16.9.4
M Изменение графика синхронизации с внешними информационными
ресурсами
R2.16.10
M Создание, редактирование отчетных форм при помощи мастера
отчетных форм позволяющий создавать и редактировать отчетные
формы с использованием полей из базы данных Системы. Данный
процесс включает, как минимум:
R2.16.10.1
M Создание отчетных форм
R2.16.10.2
M Редактирование отчетных форм
R2.16.10.3
M Удаление отчетных форм
R2.16.10.4
M Настройка прав пользователей на использование отчетных форм
R2.17
Модуль «17. Лабораторная информационная система»
R2.17.1
M Регистрация поступившего материала с возможностью отбраковки.
Данный процесс включает, как минимум:
R2.17.1.1
M Ведение персонифицированного учета проводимых исследований,
поддержка карточки пациента в базе данных ЛИС
R2.17.1.2
M Создание новой карточки пациента с присвоением уникального
идентификационного номера после: автоматически получения
данных из других модулей о поступлении нового пациента,
автоматически после получения (считывания) направления,
занесения данных пациента с направления вручную
R2.17.1.3
M Считывание бланков установленного образца с помощью:
Раздел VI. Технические требования
177
оптического распознавание символов, оптического распознавания
отметок
R2.17.1.4
M Регистрация поступившего материала с привязкой к пациенту
R2.17.1.5
M Присвоение уникального идентификационного номера каждому
материалу
R2.17.1.6
M Возможность отбраковки поступившего материала с указанием
причины (из справочника и/или вручную)
R2.17.1.7
M Формирование отчетных форм:
1. Отчет о количестве поступившего материала
2. Отчет о количестве материала отбракованного по различным
причинам
R2.17.2
M Штрих-кодирование материала (создание штрих-кодов,
идентификация по штрих-коду). Данный процесс включает, как
минимум:
R2.17.2.1
M Присвоение штрихкода материалу
R2.17.2.2
M Присвоение штрихкода отдельным образцам
R2.17.2.3
M Считывание штрихкода с помощью стационарных и переносных
сканеров штрихкодов
R2.17.2.4
M Поддержка формирования данных на основе большинства из
следующих штрихкодов Code 39, Code 93, Code 128, Codebar,
European Article Number (EAN), ITF-14, MSI Barcode, Universal
Product Code, а также двумерных кодов PDF417, Aztec Code, Data
Matrix, Maxi Code, QR-код, Microsoft Tag
R2.17.3
M Формирование рабочих листов для лабораторных анализаторов и
исполнителей. Данный процесс включает, как минимум:
R2.17.3.1
M Формирование заказов на исследования на основе поступивших из
МИС направлений
R2.17.3.2
M Формирование заказов на исследования на основе ручного ввода
данных
R2.17.3.3
M Включение в один заказ нескольких материалов
R2.17.3.4
M Использования при заказе профилей услуг (множественные
Раздел VI. Технические требования
178
исследования)
R2.17.3.5
M Заказ комплексных услуг (одна услуга с несколькими материалами)
R2.17.3.6
M Автоматическое распределение исследований по рабочим листам на
основе конфигурируемых критериев (вид исследования, время
исследования, исполнитель)
R2.17.3.7
M Ручное распределение исследований по рабочим местам
R2.17.3.8
M Перераспределение исследований из одних рабочих листов в другие
R2.17.3.9
M Изменение исполнителя в рабочем листе
R2.17.3.10
M Вывод на печать рабочих листов для организации выполнения
ручных исследований
R2.17.4
M Взаимодействие с лабораторным оборудованием (экспорт
направлений на исследование, импорт результатов исследований).
Данный процесс включает, как минимум:
R2.17.4.1
M Подключение анализаторов, станций пробоподготовки и иных
аппаратов, имеющих возможность подключения к ЛИС
R2.17.4.2
M Отправка заданий на анализаторы
R2.17.4.3
M Получение результатов от анализаторов и распределение их по
карточкам пациентов
R2.17.4.4
M Получение результатов внутрилабораторного контроля качества от
анализаторов
R2.17.4.5
M Просмотр, редактирование, удаление, обработка, утверждение
результатов
R2.17.5
M Ручной ввод результатов лабораторных исследований. Данный
процесс включает, как минимум:
R2.17.5.1
M Настройка шаблонов результатов
R2.17.5.2
M Ручной ввод готовых результатов исследований
R2.17.5.3
M Настраиваемый алгоритм расчета готовых результатов на основе
вводимых данных
R2.17.5.4
M Обработка результатов бактериологических исследований:
Раздел VI. Технические требования




179
Система обработки должна быть открытой и позволять
пользователю в рамках вложенной в нее классификации
самостоятельно дополнять такие разделы, как:
антибиотики, диагнозы, биоматериалы, микроорганизмы,
Перечень диагнозов в системе должен быть составлен
МКБ-10, список антибактериальных препаратов должен
быть составлен по международной классификации,
перечень таксонов — по последнему изданию
«Определитель бактерий Берджи»,
Антибиотикограмма должна выстраиваться на основании
данных, введенных пользователем и полученных любым из
методов (диско-диффузионным, методом предельных
концентраций или при определении минимальной
подавляющей концентрации),
Система обработки на основании заложенных в нее
данных о природной устойчивости отдельных
микроорганизмов или их групп, о распространении среди
них приобретенной резистентности, а также сведений о
клинической эффективности антибактериальных
препаратов, должна интерпретировать результаты
исследования антибиотикочувствительности, полученные
in vitro, в степень чувствительности (S, I, R) и, при
необходимости, их корректировать или выдавать
сообщение об ошибке,
R2.17.5.5
M Формирование отчетных форм:
1. Отчет о выполненных исследованиях
2. Отчет об антибиотикорезистентности выделенных культур (в
целом по Организации и по подразделениям)
3. Отчет по видам лабораторных исследований (клинические,
биохимические, гематологические, иммунологические,
бактериалогические и др.)
4. 261/у
5. 262/у
6. Форма №1 АПО (Отчет по дорогостоящим услугам в
сравнении с планом)
R2.17.6
M Подтверждение действительности результатов лабораторных
исследований уполномоченным сотрудником лаборатории. Данный
процесс включает, как минимум:
R2.17.6.1
M Просмотр результатов выполнения исследований
R2.17.6.2
M Сравнение с референсными значениями с визуальной индикацией
отклонений
Раздел VI. Технические требования
180
R2.17.6.3
M Построение контрольных карт для оценки качества результатов
R2.17.7
M Контроль качества лабораторных исследований
(внутрилабораторный, межлабораторный, внешний). Данный
процесс включает, как минимум:
R2.17.7.1
M Регистрация ежедневных результатов исследования контрольных
материалов
R2.17.7.2
M Регистрация эталонных значений контрольных материалов
R2.17.7.3
M Оценка полученных значений в соответствии с эталонными
значениями
R2.17.7.4
M Формирование протоколов исследования контрольных препаратов
для межлабораторного и внешнего сличения
R2.17.8
M Возможность вывода на печать результатов на основании
утвержденной действующими нормативными правовыми актами РК
первичной учетной документации. Данный процесс включает, как
минимум:
R2.17.8.1
M Создание и редактирование шаблонов бланков и журналов
R2.17.8.2
M Вывод результатов на печать в соответствии с утвержденными
(R2.18.10.1) и пользовательскими формами
R2.17.8.3
M Вывод журналов на печать в соответствии с утвержденными
формами (R2.18.10.1)
R2.17.9
M Введение референсных значений по лаборатории как для всех
пациентов, так и по половозрастным группам. Данный процесс
включает, как минимум:
R2.17.9.1
M Введение референсных значений по половозрастным группам
R2.17.9.2
M Формирование референсных значений отдельных показателей на
основе статистической обработки результатов лаборатории
R2.17.9.3
M Формирование отчетных форм:
1.
Референсные значения лаборатории (по группам пациентов и
по видам лабораторных исследований)
R2.17.10
M Ведение первичной учетной документации на уровне лаборатории в
соответствии с действующими нормативными правовыми актами РК.
Данный процесс включает, как минимум ведение следующих
учетных форм:
Раздел VI. Технические требования
181
R2.17.10.1
M 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/у, 2443/у,
245/у, 245-1/у, 248/у, 249/у,250/у, 252/у, 253/у, 253-1/у, 253-2/у, 254/у,
260/у, 257/у, 259/у, 261/у, 262/у,280/у,
R2.17.11
M Формирование аналитических форм на уровне лаборатории, а также
статистических таблиц в соответствии с действующими
нормативными правовыми актами РК. Данный процесс включает,
как минимум:
R2.17.11.1
M Формирование отчета лаборатории по выполненным исследованиям
(Форма 30)
R2.17.12
M Возможность интеграции Системы с самостоятельными
Лабораторными информационными системами. Данный процесс
предполагает соответствие необходимым профилям IHE.
R2.17.13
M Передача информации о выполненных исследованиях в ЭМЗ и ЭПЗ.
Данный процесс включает, как минимум:
R2.17.13.1
M Передача информации о выполненных лабораторных исследованиях
и их результатах в ЭПЗ в соответствии со Стандартными
требованиями к ЭПЗ, утвержденными приказом и.о. Министра
здравоохранения РК №75 от 10.02.2014 г «Об утверждении
технической документации по вопросам электронного
здравоохранения»
R2.17.13.2
M Передача информации о выполненных лабораторных исследованиях
и их результатах в ЭМЗ в соответствии со Стандартными
требованиями к ЭМЗ, утвержденными приказом и.о. Министра
здравоохранения РК №75 от 10.02.2014 г «Об утверждении
технической документации по вопросам электронного
здравоохранения»
R2.18
R2.18.1
Модуль «18. PACS» (Picture Archiving and Communication System)
M Обмен данными с медоборудованием. Данный процесс включает, как
минимум:
Раздел VI. Технические требования
182
R2.18.1.1
M Импорт данных в соответствии со стандартом DICOM (Остраслевой
стандарт создания, хранения, передачи и визуализации медицинских
изображений)
R2.18.1.2
M Импорт напрямую с видеовыходов (при наличии необходимого
оборудования)
R2.18.2
M Взаимодействие с другими модулями и системами на основе правил
IHE профилей
R2.18.3
M Импорт/экспорт изображений. Данный процесс включает, как
минимум:
R2.18.3.1
M Поддержать форматы не менее чем DICOM. BMP, JPEG
R2.18.3.2
M Поддержка не менее чем DICOM Modality Worklist
R2.18.3.3
M Возможность сохранения изображений как приложения к
документам CDA
R2.18.3.4
M Поддержка сканирования бумажных и пленочных изображений для
составления электронного архива
R2.18.3.5
M Аудит случаев импорта-экспорта
R2.18.4
M Работа с изображениями. Данный процесс включает, как минимум:
R2.18.4.1
M Просмотр единичных и серий изображений,
R2.18.4.2
M Вызов из архива и появление изображения на экран не позже чем 3-5
сек после запроса
R2.18.4.3
M Выделение областей интереса на изображении,
R2.18.4.4
M Наложение комментариев
R2.18.4.5
M Обработка изображений для улучшения качества
R2.18.4.6
M Быстрый поиск данных о пациенте и изображений пациента
R2.18.4.7
M Связь метаданных пациента с изображениями
R2.18.4.8
M Связь изображений с интерпретацией и диагностическими
результатами
Раздел VI. Технические требования
183
R2.18.4.9
M Аудит просмотра и обработки изображений
R2.18.5
M Ведение архива изображений. Данный процесс включает, как
минимум:
R2.18.5.1
M Возможность долгосрочного хранения изображений
R2.18.5.2
M Хранение идентификационных данных пациента во избежание
ошибок присвоения изображений другими пациентами.
R2.18.5.3
M Возможность интеграции с другими системами организации
R2.18.5.4
M Возможность передачи изображений (при необходимости) в других
системах и в национальный репозиторий ЭПЗ
R2.19
Модуль «19. Диагностические исследования»
R2.19.1
M Просмотр записанных по графику пациентов. Данный процесс
включает, как минимум:
R2.19.1.1
M Просмотр графика с записанными пациентами
R2.19.1.2
M Просмотр направлений, созданных на диагностические исследования
R2.19.1.3
M Получение списка пациентов, записанных на исследования
R2.19.1.4
M Отмена или перенос времени исследования с указанием причины
переноса и уведомлением заинтересованных сторон
R2.19.1.5
M Формирование отчетных форм:
1.
Отчет о записанных на прием
2.
Отчет об отмененных посещениях
3.
Отчет о выполненных услугах
4.
Отчет о дозах облучения персонала и пациента
5.
Отчет по очередности и сроком ожидания диагностических
исследований
6.
Формирование списка пациентов в разрезе оказанных услуг
по кодам тарификатора
R2.19.2
M Ввод результатов исследований на основе шаблонов. Данный
процесс включает, как минимум:
R2.19.2.1
M Создание и редактирование шаблонов консультаций, заключений,
Раздел VI. Технические требования
184
результатов исследований
R2.19.2.2
M Заполнение результатов исследований на основе шаблонов
R2.19.2.3
M Поиск предыдущих заключений пациента
R2.19.2.4
M Вывод результатов исследований на печать в утвержденной форме
R2.19.2.5
M Формирование отчетных форм:
1.
Отчет о выполненных услугах (в разрезе аппаратов,
исполнителей, источников финансирования, видов исследований,
направляющих подразделений)
2.
Отчет о дозах облучения персонала и пациента
3.
Список пациентов в разрезе оказанных услуг по кодам
тарификатора
R2.19.3
M Ведение первичной учетной документации по диагностическим
исследованиям в соответствии с действующими нормативными
правовыми актами РК. Данный процесс включает, как минимум
ведение следующих учетных форм:
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/у, 247-2/у, 247-3/у, 247-3/1/у ,247-3/2/у, 247-4/у, 247-5/у, 2476/у, 247-7/у,
R2.19.3.2
M Протокол измерения индивидуальных доз (приказ МЗ РК №902 от
20.12.11 г)
R2.19.4
M Формирование аналитических форм по диагностическим
исследованиям, а также статистических таблиц в соответствии с
действующими нормативными правовыми актами РК. Перечень
аналитических и статистических форм должен быть согласован с
Заказчиком на этапе проектирования Системы.
R2.19.5
M Передача информации о выполненных исследованиях в ЭМЗ и ЭПЗ.
Данный процесс включает, как минимум:
R2.19.5.1
M Передача информации о выполненных диагностических
исследованиях и их результатах в ЭПЗ в соответствии со
Стандартными требованиями к ЭПЗ, утвержденными приказом и.о.
Министра здравоохранения РК №75 от 10.02.2014 г «Об
утверждении технической документации по вопросам электронного
здравоохранения»
Раздел VI. Технические требования
185
R2.19.5.2
M Передача информации о выполненных диагностических
исследованиях и их результатах в ЭМЗ в соответствии со
Стандартными требованиями к ЭМЗ, утвержденными приказом и.о.
Министра здравоохранения РК №75 от 10.02.2014 г «Об
утверждении технической документации по вопросам электронного
здравоохранения»
R2.19.5.3
M Осуществление обмена в соответствии с IHE профилями
R2.20
Модуль «20. Аптека»
R2.20.1
M Ведение учета медикаментов на разных уровнях: поста, кабинета,
отделения, аптечного склада (одного или нескольких), медицинской
организации. Данный процесс включает, как минимум:
R2.20.1.1
M Ведение полноценного складского учета на одном или нескольких
центральных складах
R2.20.1.2
M Ведение полноценного складского учета для каждого материально
ответственного лица
R2.20.1.3
M Просмотр складских остатков по каждому складу (по группе
медикаментов, по фармакологическим и фармакотоксическим
группам, по медикаменту, по поставщику, по отделению)
R2.20.1.4
M Установление количества неснижаемых остатков по каждому
медикаменту
R2.20.1.5
M Установление базовых перечней медикаментов для каждого
отделения
R2.20.1.6
M Контроль за исполнением неснижаемых остатков
R2.20.2
M Автоматическое списание лекарственных средств при выполнении
назначения.
R2.20.3
M Возможность отслеживания сроков годности ЛС и ИМН.
R2.20.4
M Возможность формирования перечня лекарственных средств
(изделия медицинского назначения) необходимых для закупа в
организациях.
R2.20.5
M Формирование требований в аптеку на получение лекарственных
средств (автоматические срочные требования при наличии в листе
назначений и отсутствии в отделении, при снижении запаса ниже
установленного критического минимума). Данный процесс
включает, как минимум:
Раздел VI. Технические требования
186
R2.20.6
M Получение сведений о наличии лекарственного препарата в
отделениях МО. Данный процесс включает, как минимум:
R2.20.7
M Ведение формуляра лекарственных средств медицинской
организации. Данный процесс включает, как минимум:
R2.20.7.1
M Создание формуляра Организации
R2.20.7.2
M Внесение лекарственных препаратов в формуляр Организации с
указанием документа, являющегося основанием
R2.20.7.3
M Исключение лекарственных препаратов из формуляра Организации с
указанием документа, являющегося основанием
R2.20.8
M Регистрация побочного действия (ПД) лекарственного средства.
Данный процесс включает, как минимум:
R2.20.8.1
M Формирование карты-сообщения (форма №192-1/у приказ
и.о.Министра здравоохранения Республики Казахстан от 03 ноября
2009 года №647)
R2.20.8.2
M Регистрация случая в Журнале регистрации выявленных случаев
побочных действий (форма №192-3/у приказ и.о.Министра
здравоохранения Республики Казахстан от 03 ноября 2009 года
№647)
R2.20.8.3
M Формирование отчетных форм:
1.
Формирование статистического отчета о случаях побочных
действий,
серьезных
побочных
действий
и
отсутствия
эффективности (ПД, СПД и ОЭ) лекарственных средств (ЛС) в
медицинских и фармацевтических организациях (форма №192-4/у
приказ и.о.Министра здравоохранения Республики Казахстан от 03
ноября 2009 года №647)
R2.20.9
M Мониторинг назначений лекарственных средств. Данный процесс
включает, как минимум:
R2.20.9.1
M Просмотр назначений лекарственных препаратов в подразделениях
Организации
R2.20.9.2
M Сортировка назначений по дате, врачу, диагнозу, и иным параметрам
R2.20.9.3
M Просмотр связки диагноз-лекарственный препарат
R2.20.9.4
M Ввод данных о препаратах, рекомендуемых клинических руководств
и протоколов диагностики и лечения
Раздел VI. Технические требования
187
R2.20.9.5
M Ввод данных о взаимодействии лекарственных средств, для
предотвращения их совместного назначения
R2.20.9.6
M Сравнение назначений с перечнем в соответствии с клиническими
протоколами и руководствами
R2.20.9.7
M Направление сообщений с рекомендацией о замене лекарственных
препаратов
R2.20.10
M Установка максимальных дозировок для контроля назначений.
Данный процесс включает, как минимум:
R2.20.10.1
M Установка максимальных дозировок в различных видах (на кг МТ,
разовая, суточная и т.д.)
R2.20.10.2
M Установка максимальных дозировок для различных
возрастнополовых групп пациентов
R2.20.10.3
M Установка максимальных дозировок для отдельных нозологий
R2.20.10.4
M Просмотр заявок на превышение установленных максимальных
дозировок
R2.20.10.5
M Разрешение на превышение установленных максимальных дозировок
с указанием причин
R2.20.11
M Регистрация и оформление приходных/расходных документов
отделений и аптеки в соответствии с нормативно-правовыми акта.
Данный процесс включает, как минимум:
R2.20.11.1
M Создание, редактирование и регистрация приходно-расходных
фактур
R2.20.11.2
M Создание, редактирование и регистрация отложенных приходнорасходных фактур
R2.20.11.3
M Формирование требований на медикаменты от старших медицинских
сестер отделений, в том числе на основе зарегистрированных
назначений
R2.20.11.4
M Оформление накладной на медикаменты и расходные материалы по
требованиям на поставку медикаментов от старших сестер отделений
R2.20.11.5
M Создание, редактирование и регистрация накладной возврата
медикаментов на склад из отделений
R2.20.11.6
M Создание, редактирование и регистрация заказов поставщикам
Раздел VI. Технические требования
188
R2.20.11.7
M Создание, редактирование и регистрация отложенных приходнорасходных фактур по выполнению заказов на медикаменты
R2.20.12
M Ведение первичной учетной документации на уровне аптеки в
соответствии с действующими нормативными правовыми актами РК.
R2.20.13
M Формирование аналитических форм на уровне аптеки, а также
статистических таблиц в соответствии с действующими
нормативными правовыми актами РК. Перечень аналитических и
статистических форм должен быть согласован с Заказчиком на этапе
проектирования Системы.
R2.20.14
M Формирование заявки на необходимые лекарственные средства на
уровне отделения, поликлиники, стационара по территории
обслуживания
R2.20.15
M Формирование отчета по планированию расходов на лекарственные
средства с учетом льготных препаратов.
R2.20.16
M Взаимодействие с другими модулями при необходимости обмена
информацией о лекарственных препаратах
R2.21
Модуль «21. Кадры»
R2.21.1
M Связь с национальными индексами. Данный процесс включает, как
минимум связь со следующими индексами:
R2.21.1.1
M «Регистр медицинских работников »
R2.21.1.2
M «Регистр организаций здравоохранения»
R2.21.1.3
M «Адресный регистр»
R2.21.1.4
M «Специальностей здравоохранения»
R2.21.1.5
M «Список должностей (функций)»
R2.21.1.6
M «Список медицинских услуг»
R2.21.2
M Ведение организационной структуры МО. Данный процесс
включает, как минимум:
R2.21.2.1
M Создание, редактирование, удаление подразделений медицинских
организаций (кабинетов, подразделений, отделений, департаментов
и др.- в соответствии с организационной структурой организаций)
Раздел VI. Технические требования
189
R2.21.2.2
M Ведение штатного расписания организации
R2.21.2.3
M Формирование ведомостей замены должностей
R2.21.2.4
M Связь между кабинетами/офисами и специалистами,
предоставляющими услуги
R2.21.2.5
M Связь подразделений со списком предоставляемых услуг
R2.21.3
M Ведение учетной карточки врача (работника здравоохранения).
Данный процесс включает, как минимум:
R2.21.3.1
M Прием сотрудника на работу
R2.21.3.2
M Ввод следющией минимальной информации о сотруднике:
История трудовых отношений, эпизоды трудовой деятельности,
личные сведения (номер удостоверения, номер пенсионного
договора, состоит ли в браке, состав семьи, место жительства, место
прописки, контактная информация, количество детей, отношение к
воинской службе, номер индивидуального трудового договора),
информация о участии в боевых действиях, ликвидации аварий,
стихийных бедствий, поощрения, взыскания, знание языков,
информация о социальных наградах, об образовании, сертификатах
специалиста, повышениях квалификации, ученых званиях, ученых
степенях.
R2.21.3.3
M Регистрация материальной ответственности сотрудников
R2.21.3.4
M Прием на дополнительную должность
R2.21.3.5
M Перевод на другую должность в Организации
R2.21.3.6
M Увольнение сотрудника
R2.21.3.7
M Ведение графиков повышения квалификации
R2.21.3.8
M Просмотр и печать списка работников отобранных по определенным
критериям
R2.21.4
M Ведение режима работы работников. Данный процесс включает, как
минимум:
R2.21.4.1
M Планирование и учет выходных и отпусков работников
Раздел VI. Технические требования
190
R2.21.4.2
M Составление режима работы с учетом выходных и отпусков
R2.21.4.3
M Учет замен и незапланированных пропусков работы
R2.21.4.4
M Печать режима работы и графиков отпусков по отдельным
работникам, по кабинетам (точек представления медицинских
услуг), по управлениям/ отделениям, по организации
R2.21.4.5
M Печать ведомостей фактически отработанного времени, отпусков по
отдельным работникам, по кабинетам (точек представления
медицинских услуг), по управлениям/ отделениям, по организации
R2.21.5
M Ведение справочника услуг. Данный процесс включает, как
минимум:
R2.21.5.1
M Связь с национальным индексом услуг
R2.21.5.2
M Добавление и удаление услуг из справочника услуг организации
R2.21.5.3
M Привязка предоставленных услуг к подразделениям организации
R2.21.5.4
M Просмотр/ печать списка услуг каждого подразделения и
организации в целом
R2.21.6
M Связь с информационной системой бухгалтерского учета (как
минимум с бухгалтерскими продуктами «1С» версии 8). Данный
процесс включает, как минимум:
R2.21.6.1
M Передача данных о новых сотрудниках
R2.21.6.2
M Передача данных об измененных должностях
R2.21.6.3
M Передача данных об отработанных днях (часах) работников
R2.21.6.4
M Обмен информацией об отпусках
R3
Требования к конфигурации системы
R3.1
Конфигурация к потребностям медицинских организаций
R3.1.1
М Поставляемая система должна содержать в свой состав обязательные
модули в соответствии с Таблицей 1 в зависимости от типа
медицинской организации: Стационар, Поликлиника, Смешанного
типа (Стационар + Поликлиника) (см. также R1.17-R1.18)
Раздел VI. Технические требования
191
R3.1.2
М Система должна обеспечить возможность управления доступом к
функционалу на основе ролей. Система должна позволять
добавлять/удалять/редактировать роли и присвоить/отменить право
доступа к функционалу системы.
R3.1.3
М Система должна иметь предустановленные роли в соответствии с
Таблицей 3 с возможностью дальнейшего изменения (добавления
новых ролей, редактирования или удаления).
R3.1.4
М Права доступа к различным модулям и функциям системы должны
быть предустановлены в соответствии с Таблицей 4 с возможностью
изменения прав доступа (добавления, удаления)
R3.1.5
М Права доступа должны быть как минимум конфигурируемыми по
следующим аспектам: все права, создание, изменение, удаление,
просмотр.
Таблица 3. Описание ролей системы
№
Наименование роли
1.
Составитель графиков
2.
Медицинский
регистратор
3.
Старшая медицинская
сестра
Описание
Специалист ответственный за формирование
графиков выполнения услуги (приема,
консультации, работы аппарата).
Должность: медрегистратор, старшая медицинская
сестра, заведующий отделением.
Специалист регистратуры амбулаторнополиклинической организации. Осуществляет
функции справочной, а также записи на прием к
участковым врачам и профильным специалистам.
Принимает и регистрирует вызовы на дом и
переданные активы (посещения по инициативе
медицинских работников).
Должность: медсестра, медрегистратор
Специалист координирующий работу среднего
медицинского персонала отделения или
организации. Ведет учет расходования
лекарственных препаратов и ИМН в отделении,
оформляет требования на выдачу лекарственных
препаратов и ИМН. Может осуществлять функции
медицинской сестры.
Должность: Старшая медсестра, главная медсестра,
заместитель главного врача по сестринскому делу
Раздел VI. Технические требования
4.
Заведующий отделением
поликлиники
5.
Участковый врач
6.
Врач профилактического
отделения
7.
Профильный специалист
8.
Главный врач
9.
Медицинский статистик
поликлиники
192
Специалист координирующий работу врачебного
персонала отделения. Согласует выписку
длительных листов временной нетрудоспособности,
участвует в ВКК.
Должность: заведующий отделением
Специалист ПМСП. Управляет ЭПЗ, оказывает
квалифицированную помощь, осуществляет
лечебно-профилактические мероприятия
прикрепленному населению как в поликлинике так
и на дому. При необходимости создает направления
на консультативно-диагностическую помощь.
Выписывает рецепты на бесплатное лекарственное
обеспечение. Оформляет заявки на госпитализацию.
Должность: ВОП, участковый терапевт, участковый
педиатр
Специалист проводящий профилактические
осмотры целевых групп населения,
профессиональные осмотры и иные
профилактические осмотры. При необходимости
создает направления на консультативнодиагностическую помощь. Профиль специалиста
может быть как терапевтический (ВОП) так и
специализированный.
Должность: врач профилактического отделения,
окулист, ЛОР, гинеколог, терапевт, уролог,
психиатр, дерматовенеролог, профпатолог, хирург и
т.д.
Специалист оказывающий специализированную
помощь на амбулаторном уровне. Ведет
наблюдение за диспансерными группами больных
(целевые группы больных) При необходимости
создает направления на консультативнодиагностическую помощь. Должность: окулист,
ЛОР, гинеколог, терапевт, уролог, психиатр,
дерматовенеролог, профпатолог, хирург и т.д.
Первый руководитель организации. Принимает
управленческие решения, определяет политику
работы организации. Управляет кадровым составом.
Обладает правом подписи финансовых документов
Должность: Главный врач, генеральный директор,
председатель правления
Специалист по медицинской статистике.
Осуществляет сбор, обработку и анализ
статистических данных на основании первичной
Раздел VI. Технические требования
10.
Медсестра участкового
врача
11.
Медсестра
профилактического
отделения
12.
Медсестра специалиста
13.
Врач приемного покоя
14.
Медсестра приемного
покоя
15.
Заведующий отделением
стационара
16.
Медицинский статистик
стационара
193
учетной документации. Формирует отчетные
документы для предоставления в уполномоченные
органы.
Должность: Врач статистик, медицинский
статистик, помощник медицинского статистика,
заместитель главного врача по организационнометодической работе, руководитель
организационно-методического кабинета.
Специалист выполняющий лечебнопрофилактические мероприятия прикрепленному
населению под руководством и по поручению
участкового врача.
Должность: участковая медсестра, фельдшер
Специалист выполняющий профилактические
мероприятия под руководством врача
профилактического отделения или профильного
специалиста.
Должность: медсестра специалиста, фельдшер,
акушер
Специалист выполняющий профилактические
мероприятия под руководством профильного
специалиста.
Должность: медсестра специалиста, фельдшер,
акушер
Специалист осуществляющий госпитализацию
пациента в круглосуточный стационар. Производит
оформление госпитализации и отказа от нее,
производит первичное клиническое обследование и
заводит историю болезни.
Должность: врач, заведующий отделением
Специалист осуществляющий помощь в процессе
госпитализации пациента. Работает под
руководством врача приемного отделения.
Должность медсестра, старшая медсестра
Специалист координирующий работу врачебного
персонала отделения. Согласует выписку
длительных листов временной нетрудоспособности,
участвует в консилиумах.
Должность: заведующий отделением
Специалист по медицинской статистике.
Осуществляет сбор, обработку и анализ
статистических данных на основании первичной
учетной документации. Формирует отчетные
документы для предоставления в уполномоченные
органы.
Должность: Медицинский статистик, помощник
Раздел VI. Технические требования
17.
Врач стационара
18.
Медсестра стационара
19.
Специалист пищеблока
20.
Администратор
21.
Лаборант
22.
Специалист лаборатории
23.
Врач-лаборант
24.
Врач диагностического
отделения
25.
Фармацевт
194
медицинского статистика, заместитель главного
врача по организационно-методической работе,
руководитель организационно-методического
кабинета.
Специалист оказывающий специализированную и
высокоспециализированную помощь в условиях
стационара. При необходимости создает
направления на консультативно-диагностическую
помощь внутри стационара. Оформляет документы
о госпитализации (история болезни, форма 066/у,
выписной эпикриз)
Должность: терапевт, педиатр, окулист, ЛОР,
гинеколог, терапевт, уролог, психиатр,
дерматовенеролог, профпатолог, хирург и т.д.
Специалист выполняющий назначения врача и
непосредственно осуществляющий уход за
пациентом.
Должность: Постовая медсестра, медсестра
процедурного кабинета, медсестра специалиста,
старшая медсестра, главная медсестра, акушер
Специалист осуществляющий расчет и подготовку
питания для пациентов.
Должности: диетолог, медсестра диетолога, повар
Специалист осуществляющий техническую
поддержку работы Системы и ее конфигурацию.
Должность: специалист по информационным
системам, системный администратор, программист.
Специалист осуществляющий выполнение
лабораторных исследований под контролем
специалиста лаборатории или врача-лаборанта
Должность: лаборант, фельдшер-лаборант
Специалист осуществляющий выполнение
лабораторных исследований под контролем врачалаборанта.
Должность: специалист лаборатории
Специалист осуществляющий выполнение
лабораторных исследований и контроль за их
достоверностью и качеством.
Должность: врач-лаборант
Специалист осуществляющий диагностические
исследования по направлениям лечащих врачей.
Должность: врач-рентгенолог, врач функциональной
диагностики, врач УЗИ.
Специалист по производству, хранению и
реализации лекарственных средств, работает под
руководством провизора.
Раздел VI. Технические требования
26.
Провизор
27.
Клинический фармаколог
28.
Специалист отдела
кадров
1.1.4
195
Должность: фармацевт
Специалист по производству, хранению и
реализации лекарственных средств
Должность: провизор
Специалист по оценке воздействия лекарственных
препаратов на организм больного человека.
Консультирует врачей по поводу назначения
лекарственных препаратов и корректировке курсов
лечения.
Должность: клинический фармаколог
Специалист по оформлению трудовых отношений,
учету кадров и данных о них
Должность: Руководитель отдела кадров,
специалист отдела кадров
Правовые документы
Минимальный набор правовых актов, которые надо соблюсти:
1) Закон Республики Казахстан «О национальной безопасности Республики
Казахстан»
№
527-IV
от
6
января
2012
года
(http://online.zakon.kz/Document/?doc_id=31106860);
2) Указ Президента от 14 ноября 2011 года № 174 " О концепции информационной
безопасности РК 2016» (http://ru.government.kz/docs/u110000017420111114.htm);
3) Кодекс РК N 193-IV от 18 сентября 2009 года “О здоровье народа и системе
здравоохранения”;
4) Закон “О персональных данных и их защите” N 94-V от 21 мая 2013
(http://online.zakon.kz/Document/?doc_id=31396226);
5) Приказ и.о. Министра здравоохранения Республики Казахстан от 23 ноября
2010 года № 907 «Об утверждении форм первичной медицинской
документации организаций здравоохранения»
6) Приказ и.о. Министра здравоохранения РК №75 от 10.02.2014 г «Об
утверждении технической документации по вопросам электронного
здравоохранения». (https://www.mzsr.gov.kz/node/319759)
1.2
Требования к функциональным характеристикам Системы
1.2.2 Нефункциональные требования к системе
1.2.2.1 Требования к времени реакции системы
Таблица ниже содержит список требований к функциональной производительности
Системы, которым должны соответствовать поставляемая Система и связанные с ней
системы/сервисы.
N
Тип Требование
Раздел VI. Технические требования
R4.1
M
Поиск пациента по ФИО или ИИН а также связанных с
пациентом данных (результаты обследования, результаты
лабораторных исследований и другое) не должен занимать более
5 секунд для 80% случаев
М
Поставщик в течение гарантийного срока должен обеспечивать
следующие параметры функционирования системы:
М
Суммарное время простоя Системы по причинам, связанным с ее
работоспособностью не должно превышать 24 часов в год.
М
Время однократного простоя Системы по причинам, связанным с
ее работоспособностью не должно превышать 2 часов.
R4.2
R4.2.1
R4.2.2
196
1.2.2.2 Требования к информационной безопасности системы
Требования к информационной безопасности
R5
R5.1.
M
Требования безопасности определяются действующим
законодательством Республики Казахстан. Система должна
соответствовать требованиям информационной безопасности по
обеспечению порогового доступа, защите от
несанкционированного доступа и др.
R5.2.
M
В системе должны быть предусмотрены средства защиты
информации от несанкционированного доступа, а именно:
R5.3.
M
Идентификация пользователя на основе проверки имени (логина)
пользователя и пароля
R5.4.
M
Возможность идентификации пользователя, основанной на
цифровых сертификатах инфраструктуры открытых ключей
R5.5.
M
Авторизация пользователя для доступа к информационновычислительным ресурсам Системы, требующим наличия
соответствующих разрешений
R5.6.
M
Персонифицированное определение прав пользователей на ввод,
корректировку, просмотр данных
Раздел VI. Технические требования
197
R5.7.
M
Персонифицированное определение прав пользователей на доступ
к ресурсам Системы
R5.8.
M
Разграничение прав пользователей системы по ролям, группам и
уровню доступа с учётом иерархии объектов и принадлежности к
организационной структуре.
R5.9.
M
Протоколирование работы пользователей с критическими
функциями и приложениями Системы
R5.10.
M
Защиту системных файлов от изменения/повреждения
неавторизованными пользователями и программными процессами
R5.11.
M
Должен вестись контрольный журнал всех обновлений в
библиотеках системных программ
R5.12.
M
В системе должны быть реализованы не менее чем следующие
средства резервного копирования:
- автоматическое резервное копирование с возможностью
планирования
- удаленное управление созданием резервной копии
- полное и частичное резервное копирование
R5.13.
M
Система должна обеспечивать целостность данных.
R5.14.
M
Система должна предоставлять инструменты для шифрования
конфиденциальных данных во время хранения и в процессе
передачи в другие системы.
R5.15.
M
Электронно-цифровая подпись (далее - регистрационное
свидетельство пользователя Национальным Удостоверяющим
Центром Республики Казахстан, ЭЦП) должна быть выпущена
НУЦ РК. Система должна обеспечить инструменты для цифровой
подписи документов (объектов) или частей документов, когда/если
это необходимо, и инструменты для аутентификации подписей.
Эта возможность должна быть реализована в сервисах Системы
(если это необходимо). Для обеспечения подтвреждения
полдинности ЭЦП и действительности открытого ключа ЭЦП,
Система должна осушествлять проверки подлинности ЭЦП
посредством сервисов НУЦ РК. (http://pki.gov.kz/index.php/ru/).
R5.16.
M
Система должна соответствовать принципу «единой точки
доступа» - архитектура информационной инфраструктуры
позволяющая иметь общую точку доступа (технология Single Sign
On) ко всем ее компонентам и ресурсам, что позволяет ввести
логин и пароль один раз и получить доступ ко всем компонентам
Системы без повторного ввода пароля.
Раздел VI. Технические требования
198
R5.17.
M
Система должна обеспечивать авторизацию пользователей в
Системе, разграничение прав пользователей системы по ролям,
группам и уровню доступа с учётом иерархии объектов и
принадлежности к организационной структуре.
R5.18.
M
В соответствии с нормативно-технической документацией по
информационной безопасности, утвержденной МЗСР РК должно
быть реализовано следующее:
− длина пароля должна быть не менее 8 символов,
должны присутствовать буквы и цифры в верхнем и нижнем
регистрах;
− функция принудительной смены пароля;
− функция запрета использования в качестве пароля
«пустой» пароль;
− самостоятельная смена пароля пользователем;
− при введении неправильного пароля более трех раз
должен быть реализован метод CAPTCHA;
− журнал логирования действий всех пользователей,
предназначенный для просмотра истории изменений
основных событий Системы;
− функционал прерывания сессии при неактивности
через N количество времени.
1.2.2.3 Требования к атрибутам качества системы
N
R6
Тип
Требование
Требования к атрибутам качества системы
R6.1.
M
Система должна поддерживать ввод, получение и передачу данных
необходимых для работы ИС МЗСР РК используемых
Организацией и исключать необходимость повторного ввода
данных.
R6.2.
M
Система должна обеспечивать сохранение всей накопленной на
момент отказа или выхода из строя информации при отказе любого
компонента Системы независимо от его назначения, с
последующим восстановлением после проведения ремонтных и
восстановительных работ
R6.3.
M
Система должна иметь возможность гибкой настройки при
изменении внешней среды и конкретных задач пользователя без
замены модулей.
R6.4.
M
Система должна быть высоко масштабируемой и позволять
работать в системе неограниченному количеству пользователей.
Ограничения могут обуславливаться только техническими
Раздел VI. Технические требования
199
характеристиками оборудования, а не характеристиками Системы
R6.5.
M
Все функциональные возможности системы должны быть
разработаны в виде сервисов.
R6.6.
M
Веб-сервисы Системы должны быть разработаны в соответствии с
СОА архитектурой.
R6.7.
М
При реализации сервисов взаимодействия обязательно
придерживаться стандарта МЗСР РК. Касающегося взаимодействия
информационных систем
R6.8.
M
Система должна предусматривать возможность конструирования
шаблонов утвержденных медицинских форм, доступных в пределах
самого решения, которые могут быть автоматизированы без
программирования или внесения изменений в программный код.
R6.9.
M
Система должна обеспечивать разрешение конфликтов при
параллельной обработке объектов системы.
R6.10.
M
Требования к пользовательскому интерфейсу
R6.10.1
M
Интерфейс должен быть рассчитан на преимущественное
использование манипулятора типа «мышь», то есть управление
системой должно осуществляться с помощью набора экранных
меню, кнопок, значков и тому подобных элементов
R6.10.2
M
Клавиатурный режим ввода должен использоваться главным
образом при заполнении и/или редактировании текстовых и
числовых полей экранных форм. Также должны быть
предусмотрены горячие клавиши для перехода между
заполняемыми полями.
R6.10.3
M
Эргономические решения и дизайн интерфейсов по возможности
должны быть едиными для всех компонентов и модулей Системы
R6.10.4
M
Пользовательский интерфейс Системы должен быть многоязычным
и организован с поддержкой не менее чем государственного
(Казахсткого) и русского языков. Исключения могут составлять
только системные сообщения, не подлежащие локализации или
стандартные административные приложения, входящие в состав
общесистемного программного обеспечения
R6.10.5
M
Должен быть обеспечен доступ к электронному комплекту
эксплуатационной документации
R6.10.6
M
В системе должна быть реализована контекстно-зависимая
Раздел VI. Технические требования
200
справочная система, доступная из любых страниц веб-приложения,
где должны быть представлены ссылки на информацию
(Руководство пользователя, инструкции и др.) для работы, с
возможностью конфигурации без привлечения Потенциального
Поставщика на уровне Покупателя;
R6.10.7
M
В пользовательском интерфейсе Системы должно быть
предусмотрено визуальное выделение на экране атрибутов,
доступных оператору только для чтения
R6.10.8
M
В пользовательском интерфейсе Системы должно быть
предусмотрено визуальное выделение на экране атрибутов,
обязательных для заполнения
R6.10.9
M
Система должна обеспечивать корректную обработку аварийных
ситуаций, вызванных неверными действиями пользователей,
неверным форматом или недопустимыми значениями входных
данных. В указанных случаях Система должна выдавать
пользователю соответствующие сообщения, после чего
возвращаться в рабочее состояние, предшествовавшее неверной
(недопустимой) команде или некорректному вводу данных
R6.10.10 M
Система не должна позволять дублирование и повторный
(ошибочный) ввод однородной информации. Система должна
обеспечивать исключение дублирования и повторного ввода
информации, содержащейся в государственных базах данных и
информационных системах государственных органов.
R6.10.11 M
Система должна обеспечивать форматно-логический контроль
вводимых данных. Под форматно-логическим контролем вводимых
данных понимается контроль на формат и содержание вводимых
данных. При работе Системой должна быть предусмотрена защита
от ошибочных действий:
- выбор только доступных для пользователя (в соответствии с
правами доступа) функций;
- ввод только доступных для пользователя (в соответствии с
правами доступа) значений;
- ввод данных только определенного формата (например,
невозможность ввода символьных данных в поле формата «Дата»
или «Число»).
1.3
№
R7
Требования к взаимодействию Системы
Тип
Требование
Требования к взаимодействию Системы
Раздел VI. Технические требования
201
Общие требования к интероперабельности Системы
R7.1.
R7.1.1
M
Решения и приложения Системы должны соответствовать
стандартам интероперабельности, в том числе национальным
стандартам и принятым международным стандартам,
перечисленным в этой главе (и в этом документе).
R7.1.2
M
Компоненты Системы должны соответствовать национальным
инструментам семантики:
o Справочники и классификаторы
o Требования к сервисам справочников
o Требования к регистрам и сервисам регистров
o Требования к управлению ресурсами и бухгалтерскому
учету
Детали по требованиям для этих инструментов приведены в этом
разделе ниже (R7.3).
R7.1.3
I
Совместимость со стандартами
R7.2.
R7.2.1
Некоторые из инструментов совместимости, описанных ниже,
находятся в процессе развития и последние версии предоставляются
потенциальным поставщикам по запросу. Основные стандарты
приведены на сайте МЗСР РК (Приказ №75 от 10.02.2014 г,
https://www.mzsr.gov.kz/node/319759)
M
Компоненты Системы должны быть совместимы не менее чем со
следующими стандартами МЗСР РК:
1) Стандартные требования к электронному паспорту здоровья
(требующий соблюдения EN 13940)
2) Стандартные требования к электронной медицинской записи
(требующий соблюдения EN13940)
3) Стандартные требования к идентификации действующих сторон
здравоохранения, используемых в системах электронного
здравоохранения
4) Технические требования к взаимодействию (передаче сообщений)
с информационными системами электронного здравоохранения
5) Регламент по обеспечению информационной безопасности
6) Стандартные требования к единому классификатору
лекарственных средств, изделий медицинского назначения и
медицинской техники
7) Стандартные требования к реализации и регулированию
электронных направлений
8) Регламент взаимодействия заинтересованных сторон с целью
обеспечения интероперабельности информационных систем и
управления информационными потоками
Раздел VI. Технические требования
202
9) Стандарт регулирования ведения рецептов в электронном
формате
10) Стандарт управления электронными процессами
диагностических исследований и лечебных процедур
11) Стандарт регулирования электронной профилактики
заболеваний
Указанные стандарты и нормативные документы доступны по
ссылке https://www.mzsr.gov.kz/taxonomy/term/619
R7.2.2
M
Компоненты Системы должны быть совместимы со следующими
международными стандартами:
a. EN 13940 (в части необходимости соответствия
стандартам ЭПЗ и ЭМЗ)
b. HL7 (ISO/HL7 27831), HL7 (v2 или V3 или FHIR);
c. HL7 CDA R2 (ISO/ HL7 27932)
d. DICOM
R7.2.3
M
Система должна соответствовать требованиям стандартам по
информационной безопасности:
 СТ РК ИСО/МЭК 27001-2008 «Методы и средства
обеспечения безопасности системы управления
информационной безопасностью. Требования»;
 СТ РК ИСО/МЭК 27002-2009 «Информационная технология.
Средства обеспечения. Свод правил по управлению защитой
информации».
Требования к совместимости с национальными
идентификаторов и стандартными классификаторами /
справочниками
R7.3.
R7.3.1
M
Компоненты Системы должны поддерживать и соответствовать
требованиям к национальным идентификаторам:
- Идентификатор Пациентов
- Идентификатор организаций здравоохранения
- Идентификатор медработников
- Идентификатор медицинской техники
R7.3.2
M
Компоненты Системы должны поддерживать и соответствовать
требованиям, как минимум по следующим классификаторам и
справочникам:
1) Национальный классификатор лекарственных средств и
медицинских материалов (картированный к АТС- DDD)
2) Классификатор медицинских услуг (на основе МКБ-9, раздел по
услугам и .3)
3) Классификатор результатов лабораторных исследований
4) Классификатор услуг и их стоимости
5) Классификатор диагнозов (МКБ-10)
Раздел VI. Технические требования
203
6) Классификатор ПМСП (ICPC-2)
7) Картирование ICPC-2 и МКБ-10
8) SNOMED, (только для цели кодирования связи между Системой и
Репозиторием ЭПЗ)
9) Для управления диагностическими услугами улучшенная система
классификации, должна быть определена на более позднем этапе;
10) Реализованная МЗ, национальная система КЗГ для
классификации пациентов (при оказании специализированной
помощи);
11) Классификатор регистров целевых групп пациентов
(Диспансерные группы);
12) Тарификатор медицинских услуг;
13) Специальностей здравоохранения;
14) Список должностей
Требования к совместимости / соответствию данных
R7.4.
R7.4.1
M
Компоненты Системы должны обеспечивать связь между Системой
и Платформой, содержащей Репозиторий ЭПЗ, основываясь на
следующих данных:
- минимальный набор данных для ЭПЗ (приводится в Приложении к
Национальному стандарту ЭПЗ и Национальному стандарту ЭМЗ)
- другие данные, не покрытые семантическими стандартами, но
необходимыми согласно НПА МЗСР РК, такие как Прикрепленные
специальные записи (документы, основанные на CDA)
R7.4.2
M
Система должна обеспечивать доступ к данным, хранящимся в
Репозитории ЭПЗ, в соответствии с 2 типами ЭПЗ: Полный ЭПЗ,
Краткий ЭПЗ. Подробности описаны в Национальном стандарте ЭПЗ
R7.4.3
M
Данные передаются между Системой и Репозиторием ЭПЗ в формате
CDA
R7.4.4
M
Система должна предоставлять возможность передачи данных в
Репозиторий ЭПЗ на основе кодов ICPC-2, которые используются в
посещениях (и контактах в целом) и картированы к МКБ-10 для
целей сбора статистики. В информационных системах ЭМЗ (кроме
систем ЭПЗ/ ПМСП) специалисты используют для кодирования
диагностики МКБ-10, и картирование в обратном направлении не
является обязательным, лишь желательным.
R7.4.5
I
Системы могут иметь дополнительные базы данных и репозитории,
необходимые для полного осуществления функциональности
(называемые ЭМЗ в контексте МЗСР РК) , но они хранятся отдельно
от базы данных репозитория ЭПЗ. Содержание Репозитория ЭПЗ
строго следует регулированию национального стандарта ЭМЗ.
Раздел VI. Технические требования
R7.4.6
M
204
Система должна быть достаточно открытой, чтобы быть способной
обеспечить интероперабельность с существующими ИС МЗСР РК,
приложениями и сервисами (см. также раздел 1.4.2).
Требования к информационному обмену
R7.5.
R7.5.1
M
Система должна взаимодействовать с национальной системой ЭПЗ в
соответствии с Национальными стандартами ЭПЗ и ЭМЗ.
R7.5.2
M
Система должна поддерживать (как минимум) взаимодействие со
следующими наборами сервисов электронного здравоохранения:
 Сервисы репозитория ЭПЗ;
 Сервисы справочной информации;
 Сервисы регистрации и регистров;
 Сервисы Клинической Номенклатуры и классификации
данных;
 Сервисы безопасного обмена информацией и обмена
сообщениями;
 Сервисы идентификации и аутентификации;
- Сервисы мониторинга и аудита для информационного обмена.
R7.5.3
M
Система должна соответствовать как
профилям IHE:
a) Инфраструктурные профили IHE:
 ATNA;
 XDS.b;
 PDQ;
 PIX;
b) Лабораторные профили IHE:
 LBL;
 LWT.
R7.5.4
М
Система должна обеспечить возможности
взаимодействия/интеграции с использованием как минимум
следующих протоколов и спецификаций:
a. Коммуникацию через SOAP (и сообщения SOAP с
приложением), REST, Message Transmission Optimization
Mechanism;
минимум
следующим
b. Поддержка стандартов и спецификаций веб-сервисов (WSSecurity, WS-Addressing, WS-Reliable Messaging, WScoordination, WS-Transaction, WS-Secure Conversation);
c. Соответствовать стандартам XML (XML, XSL, ebXML, и др.);
d. Поддерживать SSO и контроль доступа через SAML v2, JWT;
e. Поддерживать общие стандарты, такие как HTTP, HTTPS,
Раздел VI. Технические требования
205
TCP/IP, протоколы защищённых сокетов (SSL v3) и TLS;
f. Позволить использование WSDL, WADL;
g. X.509;
h. Цифровые подписи (ЭЦП НУЦ РК).
R7.5.5
М
Система должна поддерживать кодировку не менее чем UTF8.
R7.5.6
М
Система должна взаимодействовать с сервисами Платформы при
скорости канала 1 Мб/с и времени отклика не более 100 мс
R7.5.7
М
Система должна взаимодействовать с сервисами Платформы в части:
 передачи/получения уведомлений и других сведений,
носящих информационный характер на шлюз «электронного
правительства»;
 отправки SMS-уведомлений и других видов рассылки
посредством СМС-шлюза системы Мобильное правительство;
 отправки электронных писем пациентам посредством единой
электронной почтовой системой;
 получения сведений о доверенностях из государственной
информационной
системы
Единая
нотариальная
информационная система;
 получения сведений по записям на прием к врачу;
 получения минимальной информации о сотруднике.
R7.5.8
I
Сведения об основных ИС здравоохранения представлены в
Приложение 3.
1.4
Сопутствующая информация о технологии отдельных вопросов
1.4.1 Использование национальных ресурсов электронного здравоохранения и
инструментов Платформы
Система должна быть способна использовать национальные ресурсы и
опубликованные сервисы электронного здравоохранения РК
№
R8
Тип
R8.1.
M
R8.2.
M
R8.3.
M
Требование
Использование национальных ресурсов электронного
здравоохранения и инструментов Платформы
Система должна быть способна функционировать в соответствии с
общей архитектурой электронного здравоохранения (Рисунок 2)
Система должна быть способна использовать функционал и вебсервисы, опубликованные на национальном уровне для взаимодействия
с ресурсами электронного здравоохранения
Система должна быть способной использовать репозиторий ЭПЗ,
национальные классификаторы и индексы (как минимум Главный
Раздел VI. Технические требования
R8.4.
M
206
индекс пациента, индекс подразделений медицинских организаций,
индес сотрудников, индекс зданий, адресный индекс, индекс
автотранспорта, индекс медицинской техники), аналитическое
хранилище и другие национальные ресурсы, необходимые для
интеграции «под-ключ» согласно национальным стандартам
(перечисленные в Приказе МЗ РК №75 от 10.02.2014 года)
Система должна поддерживать локальные копии национальных
ресурсов и быть способной синхронизировать их на регулярной основе
(в соответствии с настраиваемым графиком) или онлайн. Система
должна содержать только информацию, касающуюся деятельности
медицинской организации. Например, Главный индекс пациентов
должен содержаться локально только для перечня пациентов,
обслуживающихся в данной организации.
1.4.2 Взаимодействие со сторонами, вовлеченными в процесс сертификации
№
R9
Тип
R9.1.
I
R9.2.
M
R9.3.
M
R9.4.
M
Требование
Взаимодействие со сторонами, вовлеченными в процесс
сертификации
Контракт связанный с поставкой Платформы и национальных ресурсов
электронного здравоохранения проводится параллельно с настоящим
контрактом. Поставщику Системы будет предоставлен доступ к
национальным ресурсам электронного здравоохранения только после
того, как параллельный контракт будет успешно реализован. В целях
облегчения параллельной реализации необходимо
синхронизировать/координировать совместные действия.
Взаимодействие вовлеченных сторон приведено на рисунке 3.
Действия, предпринимаемые Поставщиком описаны в 4 столбце
«Частные ИТ компании»
Поставщик системы должен взаимодействовать с Поставщиком
платформы, Организацией и МЗСР РК в целях тестирования и
сертификации интероперабельности с национальными ресурсами и
сервисами.
Поставщик системы должен координировать взаимодействие
вовлеченных сторон в соответствии с рисунком 3. Сертификация
заключается в проверке установленной системы на соответствие
требованиям R7.2. Покупатель уполномочит специальную комиссию,
которая совместно с Поставщиком Платформы и поставщиком данной
системы, проведут тесты в соответствии стандартам МЗСР РК, на
соответствие требованиям по интероперабельности в соответствии с
национальными станддартами, в том числе на способность корректного
взаимодействия поставленной системы, с национальными ресурсами
предоставленными в рамках платформы.
На этапе проектирования Системы (действие 4.4) Поставщик Системы
должен соблюдать требования «Регламентов разработки веб-сервисов»
Раздел VI. Технические требования
R9.5.
M
R9.6.
M
R9.7.
M
207
и «Требования к взаимодействию с Репозиторием ЭПЗ»
предоставляемые поставщиком Платформы. Поставщик Системы
может запросить дополнительную информацию при необходимости для
разработки взаимодействия с ресурсами электронного
здравоохранения.
На этапе тестирования/сертификации (действие 4.6) поставщик
Системы должен соблюдать требования и стандарты электронного
здравоохранения R7.2
Поставщик обязан сертифицировать систему до приемки в
эксплуатацию.
В случае, возникновения обстоятельств не позволяющих выполнить
требование R9.6 и происходящих не по вине Поставщика, Акты
приемки Системы могут быть подписаны без сертификации. При этом
поставщик Системы обязуется сертифицировать систему когда
появляются условия сертификации, без дополнительных затрат со
стороны Покупателя.
Раздел VI. Технические требования
Рисунок 3. Взаимодействие сторон, вовлеченных в процесс внедрения и
сертификации Системы
208
Раздел VI. Технические требования
209
1.5. Требования к поставщикам
N
R10
R10.1.
Тип
R10.2.
M
R10.3.
M
R10.4.
M
M
Требование
Требования к поставщикам
Поставщик будет поставлять свою собственную Систему
(компоненты и продукты составляющие ее) или будет уполномочен
Разработчиком/владельцем этой Системы (компонентов и продуктов
составляющих ее) на обеспечение, разработку, установку,
сопровождение продукции в соответствии с настоящим тендером.
Поставщик будет проводить обучение в стране клиента, связанное с
использованием и администрированием Системы, а также для всех
разработанных и установленных продуктов. Языками обучения будет
государственный и русский. Детали по обучению приведены в R12.2
Поставщик должен иметь офис в стране Покупателя или иметь
партнера, зарегистрированного в качестве юридического лица в
стране Покупателя, имеющего официальный статус партнера
разработчика / поставщика, или имеющего соглашение о
консорциуме, связанном с этим конкретным контрактом. Это
необходимо во время реализации, развертывания, обучения и
гарантийного срока для гладкой и надежной реализации контракта.
Поставщик должен иметь команду реализации проекта, состоящую не
менее чем из следующих специалистов (в случае необходимости, две
позиции могут быть приняты одним специалистом при условии, что
навыки будут доказаны, но не более чем 2 позиции на специалиста):
1) Бизнес-аналитик, имеющий опыт работы не менее 3 лет в ИТ
проектах электронного здравоохранения и опытом работы хотя бы в
одном аналогичном проекте;
2) Менеджер управления проекта (руководитель команды), имеющий
опыт работы не менее 3 лет в управлении проектами и опыт работы
более 1 года, с предлагаемым решением и должен иметь сертификат
управления проектами (например, PMP или IPMI);
3) Специалист СУБД имеющий, не менее 3 лет опыта работы с СУБД;
4) Специалисты с опытов работы со стандартами не менее 2 лет: HL7,
DICOM, CDA (R2), IHE;
5) Дизайнер пользовательского интерфейса, имеющий опыт работы
не менее 3 лет;
6) Технический писатель, имеющий опыт работы не менее 2 лет;
7) Специалист по связям, имеющий опыт работы в данной области не
менее 3 лет общего опыта ИТ, с отличным владением английским,
русским и казахским языками;
8) Специалист по тестированию, имеющий не менее 3 лет опыта
тестирования ПО;
9) Специалист по обучению, имеющий не менее 3 лет опыт в
проведении обучения;
Раздел VI. Технические требования
210
Все предлагаемые специалисты должны иметь высшее образование в
ИТ или взаимосвязанных областях, степень магистра
предпочтительна. Поставщик должен представит перечень
специалистов, с приложением резюме, сертификатов для
доказательства опыта работы и квалификации.
Поставщик должен представить все документы (патенты, лицензии,
свидетельства о государственной регистрации прав на объект
авторского права и т.п.) на Систему (для всех компонентов и
продуктов), демонстрирующие разрешение владельцев использовать
продукты для данного контракта или демонстрирующие владение
продуктами.
R10.5.
M
R10.6.
M
План - график оказания услуг должен быть согласован с
уполномоченной организацией Покупателя и подписан Покупателем
в течение 20 (двадцати) рабочих дней после подписания договора.
Поставщик должен своевременно оказывать услуги согласно
утвержденному план-графику.
R10.7.
I
В случае участия зарубежных компаний, консорциум является
наиболее вероятной подходящей формой участия в тендере (хотя и не
обязательной), потому что некоторые из требований предполагают
знания и навыки, которыми международные поставщики могут не
обладать - опыт работы в стране.
R10.8.
M
Производители ПО должны иметь как минимум один сертификат из
следующего перечня: Capability Maturity Model Integration (CMMI),
ISO 9000 series, СТ РК ISO 9001:2009 или эквивалент по качеству
менеджмента (Участник торгов должен предоставить копии
сертиификатов соответствия выданных уполномоченным органом).
R10.9.
M
Поставщик должен обеспечить обслуживание и техническую и
гарантийную поддержку, включая предоставление новых версий
продуктов в соответствии с R12.3 и R12.4.
R10.10. M
Поставщик должен подготовить соответствующие руководства для
всех компонентов Системы на английском, казахском и русском
языках.
R10.11. M
Поставщик должен иметь доказанный опыт работы с одним или
несколькими стандартами, используемыми в настоящем документе:
HL7 (v2, V3, FHIR), CDA (R2), IHE.
R10.12. I
Контракт, связанный с поставкой Платформы информатизации и
интероперабельности здравоохранения (далее - Платформа)
проводится параллельно с настоящим контрактом.
R10.13. M
Поставщику Системы будет предоставлен доступ к национальным
ресурсам электронного здравоохранения только после того, как
параллельный контракт будет успешно реализован. В целях
облегчения
параллельной
реализации
необходимо
Раздел VI. Технические требования
211
синхронизировать/координировать
совместные
действия
с
поставщиком Платформы. В случае, возникновения обстоятельств не
позволяющих выполнить требования по взаимодействию с
Платформой, ввиду задержки выполнения котракта по поставке
Платформы,
поставщик
Системы
обязуется
реализовать
взаимодействие, когда появятся условия, без дополнительных затрат
со стороны Покупателя.
Раздел VI. Технические требования
212
C. ТЕХНИЧЕСКИЕ СПЕЦИФИКАЦИИ
2.1. Общие технические требования к Системе
N
R11
Тип
Требование
Общие технические требования к Системе
R11.1.
M
Система быть способной работать с локального сервера через
локальную сеть, используемую одной ЛПО
R11.2.
M
Серверная часть Системы должна поддерживать работу как
минимум в операционных системах семейства Windows.
R11.3.
M
Клиентская часть Системы должна поддерживать работу как
минимум в операционных системах Windows (2008/VISTA/7/8)
(x86/x64)
R11.4.
M
Для сохранения информации в Системе должна использоваться
реляционная база данных.
R11.5.
M
База данных Системы должна поддерживать стандартный SQL,
совместимый со стандартом ANSI/ISO/IEC 9075-1992
R11.6.
M
Поставщик обязан обеспечить обслуживание и техническую
поддержку, включая предоставление новых версий продуктов до
истечения срока гарантийного обслуживания
R11.7.
M
Система должна предоставлять возможность функционирования на
удаленной инфраструктуре и в облачной (виртуализированной)
операционной среде
R11.8.
M
Система должна предоставлять возможность аутентификации с
использование технологии SSO
2.2 Спецификация услуг
Спецификация услуг
R12
Требования к наследованию данных и функционала.
R12.1.
R12.1.1
M
В случае поставки и внедрения Системы отличной от
эксплуатируемой заказчиком Поставщик осуществляет полный
комплекс необходимых работ по наследованию данных и
функционала, используемых Покупателем модулей
информационной системы с подключением к Системе
Раздел VI. Технические требования
213
используемых Покупателем программных и технических средств
автоматизации, медицинского и лабораторного оборудования.
R12.1.2
M
Обучение и учебные материалы
R12.2.
R12.2.1
Все затраты, связанные с обеспечением наследования данных и
функционала несет Поставщик.
M
Поставщик должен подготовить учебный план для обучения
следующих групп:
a) пользователи системы;
b) администраторы системы;
c) разработчики,
d) администраторы баз данных.
R12.2.2
M
R12.2.3
M
R12.2.4
M
R12.2.5
M
R12.2.6
M
R12.2.7
M
Учебный план и учебные материалы по каждой группе должны
быть согласованы с Покупателем до начала обучения.
Поставщик должен обеспечить оборудование, презентационные
материалы и пособия, необходимые для обучения
Поставщик Системы должен представить учебные материалы в
форме руководств, учебных книг и презентаций, баз знаний на
государственном и русском языках.
Поставщик должен провести обучение как минимум 80 часов для
каждой группы администраторов системы, разработчиков,
администраторов баз данных и 20 часов для пользователей каждой
медицинской организации, в которой проводится внедрение
Системы. Количество часов может быть увеличено и должно быть
достаточно для передачи знаний и навыков.
Поставщик должен проводить отдельное обучение для
пользователей, администраторов системы, разработчиков и
администраторов баз данных. Индикативное число обучаемых
определяется путем умножения на 2 общего количества
автоматизированных рабочих мест из Приложения 2. Место
обучения – юридический адрес медицинской организации –
бенефициара . Группы обучающихся должны включать не более
10 человек
Учебный план для группы (а) - пользователи системы - должен
содержать детальное разъяснение автоматизированных бизнес
процессов, использование всех компонентов системы, подробное
описание функций и взаимодействий между различными
пользователями и ролями; отчётность и другая необходимая
информация. Обучение также будет содержать практические
тренинги для понимания материала.
Учебный план для группы (b) - администраторы системы - должен
содержать описание инструментов администрирования
компонентов системы, включая важные вопросы сопровождения
системы, и аспекты технической поддержки.
Раздел VI. Технические требования
R12.2.8
M
R12.2.9
M
R12.2.10
M
R12.2.11
M
R12.2.12
M
R12.2.13
I
R12.3.
R12.3.1
M
R12.3.2
M
214
Поставщик должен провести для группы (c) разработчики один
вводный курс и один курс повышения квалификации по
предоставляемым средствам разработки и компонентам,
предусмотренных в рамках данного контракта.
Поставщик должен провести для группы (d) администраторы баз
данных один вводный курс и один курс повышения квалификации
по предоставляемой СУБД.
Обучение для групп (a) - (d) должно проводиться на русском языке
или на госсударственном языке по требованиям Покупателя.
Все тренинги проводятся тренерами в Астане или в другом месте,
указанном Покупателем.
Для всех проведенных тренингов, Поставщик должен провести
соответствующее тестирование и выдавать сертификаты.
Вышеуказанное количество и продолжительность обучения
являются минимальными требованиями. Поставщик по запросу
Покупателя может увеличить эти величины (в часах) для
достижения адекватного уровня навыков для персонала без
дополнительных затрат со стороны Покупателя. Во время этапа
подготовки проекта точное число часов, групп и содержания
курсов будут согласованы с Поставщиком.
Служба поддержки пользователей
Поставщик должен организовать службу поддержки пользователей
для консультирования по вопросам, возникающим в процессе
эксплуатации, на все время внедрения и обеспечения гарантийного
обслуживания.
Техническая поддержка Системы и её пользователей должна
осуществляться Поставщиком в режиме 24 часа в сутки, 7 дней в
неделю, в течение 2 лет с момента подписания актов ввода
Системы в эксплуатацию.
Гарантийный сервис
R12.4.
R12.4.1
M
R12.4.2
M
Поставщик Системы будет обеспечивать гарантийное
обслуживание Покупателя в течение 3 лет, начиная сразу после
согласования Покупателем Акта приемки.
Поставщик должен обеспечить разрешение запросов:
a) для критичных проблем, касающихся работоспособности
Системы и ведущих к повреждению данных, проблема
должна быть решена не более чем за 2 часов;
b) для не критичных проблем не более 2 дней.
R12.4.3
M
Гарантийное обслуживание включает в себя, но не ограничивается,
следующими категориями услуг:
- Исправление ошибок в Системе;
- Помощь Организации в правильном исправлении всех проблем с
Раздел VI. Технические требования
R12.4.4
M
215
данными, возникающими в результате ошибочной функции
приложений;
- Обеспечение технической поддержки в настройке приложения
или изменения параметров по умолчанию;
- Оказание необходимой технической помощи
квалифицированному персоналу и переподготовка, если выявлено,
что они не могут решить все проблемы после полученной
подготовки;
Формы вмешательства могут быть одним из следующих наиболее
подходящих с точки зрения качества и эффективности:
- Телефонные звонки;
- По электронной почте;
- Skype или другие Video Messenger;
- Удаленный доступ к пользователю;
- Работа на месте.
R12.4.5
M
R12.4.6
M
R12.4.7
M
Поставщик должен обеспечить в течении гарантийного срока
группу консультантов, доступных в стране Покупателя в том числе
одного менеджера и как минимум одного технического
специалиста, и предоставить всех необходимых специалистов на
расстоянии для дистанционной помощи (по мере необходимости).
Суммарное время простоя Системы по причинам, связанным с её
работоспособностью не должно превышать 24 часов в год.
Время однократного простоя Системы по причинам, связанным с
её работоспособностью не должно превышать 2 часов.
2.3. Требования к документации
N
R13
R13.1
Тип
M
Требование
Требования к документации
Поставщику необходимо предоставить следующий пакет документов:
- Программа и методика испытаний;
- Формуляр (основные характеристики, комплектность и
сведения об эксплуатации депонируемого программного
продукта);
- Описание наиболее распространенных ошибок и способов их
устранения;
- Описание структуры базы данных;
- Руководство по установке программного обеспечения;
- Руководство администратора;
- Руководство пользователя.
R13.2
M
Языками документов должны быть как минимум государственный и
Раздел VI. Технические требования
R13.3
M
R13.4
M
216
русский.
Поставщик должен предоставить 5 комплектов документации в
бумажном и электронном виде на английском, русском и казахском
языках.
Электронные версии должны поддерживать возможность
контекстового поиска.
Поставщик должен подготовить информационную систему и
нормативно-методическую документацию к проведению аттестации
на соответствие требованиям информационной безопасности согласно
со статьей 5 Закона Республики Казахстан от 11 января 2007 года «Об
информатизации» и Постановлением Правительства Республики
Казахстан от 30 декабря 2009 года № 2280 «Об утверждении Правил
проведения аттестации государственных информационных систем и
негосударственных информационных систем, интегрируемых с
государственными информационными системами, на соответствие их
требованиям информационной безопасности и принятым на
территории Республики Казахстан стандартам» и к вводу в
эксплуатацию в соответствии со статьей 17 Закона Республики
Казахстан от 11 января 2007 года «Об информатизации».
Раздел VI. Технические требования
217
D. ТЕСТИРОВАНИЕ И ТРЕБОВАНИЯ ПО ГАРАНТИИ КАЧЕСТВА
3.1. Тестирование системы и требования гарантии качества
Тестирование системы и требования гарантии качества
R14
Предпусковые работы
Поставщик Системы должен выполнять стандартные установочные
тесты для проверки корректной установки Системы.
Поставщик должен предложит в рамках технического предложения
список тестов, условий испытаний, критериев успеха и другого для
испытаний Системы.
R14.1
R14.1.1
M
R14.1.2
M
R14.1.3
I
Качество тестов является одним из критериев для технической оценки.
Список тестов будет включать в себя тесты для каждого модуля и тесты
для Системы в целом.
R14.1.4
M
R14.1.5
М
R14.1.6
М
R14.1.7
М
R14.1.8
М
R14.1.9
М
R14.1.10
М
Поставщик Системы проведет поэтапные детальные испытания, в том
числе тесты производительности, времени отклика, пропускной
способности, Системы совместно с организацией, уполномоченной
Покупателем, согласно тестам предоставленным Поставщиком.
Поставщик должен провести демонстрацию Системы с участием
представителей Покупателя и организацией, уполномоченной
Покупателем согласно сценарию испытаний Системы на любом этапе
контракта.
Поставщик должен оформить результаты демонстрации в виде
Протокола о проведении демонстрации по форме, согласованной с
Покупателем. Протокол должен быть подписан всеми участниками
демонстрации.
Место проведение демонстрации согласовываются с Покупателем и
организацией уполномоченной Покупателем.
Поставщик должен устранять замечания, полученные в ходе
проведения демонстраций, и проводить повторные демонстрации до
получения протокола об успешном проведении демонстрации.
Сроки устранения замечаний согласовываются с Покупателем.
Тестирование должно осуществляться в соответствии с одним из
стандартов IEEE 829/1009, BS 7925, ISO/AS 9100 и разработанным
документом «Программа и методика испытаний» СТ РК 1089-2002.
Поставщик должен протестировать Систему в соответствии с Web
Content Accessibility Guidelines (WCAG) 2.0. Поставщик должен
представить подробную информацию о результатах тестировании.
Поставщик должен протестировать Систему по безопасности в
соответствии с OWASP Топ 10 уязвимости. Поставщик должен
представить подробную информацию о результатах тестировании.
Раздел VI. Технические требования
R14.1.11
М
R14.2
R14.2.1
M
R14.2.2
M
R14.2.3
M
218
Поставщик должен согласовать с Покупателем сценарий тестирования
и предоставить отчёт по результату каждого тестирования.
Приемка в эксплуатацию
Акт приемки Системы подписывается на основании бесперебойной
работы при нормальных условиях эксплуатации для Системы в течении
3 месяцев. В случае выявления ошибок функционирования в данный
период Поставщик должен внести необходимые изменения и провести
повторную эксплуатацию Системы в течении 3 месяцев. Под
ошибками фунционирования понимаются критические ошибки,
которые не позволяют эксплуатировать Систему
Поставщик должен начать необходимую работу для устранения
дефектов или повреждений в течение 10 рабочих дней для некритичных
ошибок. Для критических ошибок поставщик должен начать работу,
необходимую для устранения дефектов или повреждений в течение 3
рабочих дней, обеспечить фиксацию времени и отчет о фиксации хода
каждый час в течение оперативного, а также гарантийного срока.
Критические ошибки: система не работает или работает не стабильно.
Важная функциональная составляющая не работает или недоступна.
Потеря данных или прерывание основного потока процесса. Компонент
системы непригоден из-за сбоя или неправильной функциональности.
Пользователи не могут выполнять любую работу.
Обязательным условием приемки в эксплуатацию является
сертификация системы в соответствии с требованиями R9
3.2. Требования к обеспечению контроля со стороны Покупателя
Требования к обеспечению контроля со стороны Покупателя
R15
R15.1
М
Поставщик должен с периодичностью, определенной в план-графике,
предоставлять Покупателю отчет о проделанной работе за истекший
период.
R15.2
М
Отчет должен содержать информацию о выполненных работах
Поставщика за отчетный период, в соответствии с утвержденным планграфиком, включая услуги по гарантийной поддержке, по СТП с
приложением всей утвержденной в процессе реализации договора за
отчетный период документации, включая официальную переписку, в
бумажном и электронном виде (в формате не менее pdf).
R15.3
М
Отчет должен быть согласован с организацией, уполномоченной
Покупателем.
R15.4
М
Покупатель может в любой момент исполнения договора проводить
контроль исполнения Поставщиком мероприятий и качества услуг по
Раздел VI. Технические требования
договору.
219
Раздел VI. Технические требования
220
E. ГРАФИК РЕАЛИЗАЦИИ
График реализации в табличной форме
Закупка лотов 1-9
№
пози
ции
Подсистема/ деталь
№ таблицы
конфигурации
участок /
код участка
Поставка
(заявитель
должен
указать в
Предварител
ьном планепроекте)
Установка
(недель с
даты
подписания)
Приемка
(недель с
даты
подписания)
Ориентир
для
неустойки
1.
Поставка и внедрение медицинской
информационной системы для
Усть-Каменогорской городской
больницы №1
41
54
да
2.
Поставка и внедрение медицинской
информационной системы для
Городской клинической больницы
№4 г. Алматы
41
54
да
3.
Поставка и внедрение медицинской
информационной системы для
Центра матери и ребенка г. УстьКаменогорск
41
54
да
4.
Поставка и внедрение медицинской
информационной системы для
Городской поликлиники №11 г.
Алматы
41
54
да
Раздел VI. Технические требования
№
пози
ции
Подсистема/ деталь
221
№ таблицы
конфигурации
участок /
код участка
Поставка
(заявитель
должен
указать в
Предварител
ьном планепроекте)
Установка
(недель с
даты
подписания)
Приемка
(недель с
даты
подписания)
Ориентир
для
неустойки
5.
Поставка и внедрение медицинской
информационной системы для
Регионального диагностического
центра г. Алматы
41
54
да
6.
Поставка и внедрение медицинской
информационной системы для
Поликлиники №1 г. Костанай
41
54
да
7.
Поставка и внедрение медицинской
информационной системы для
Центральной районной больницы
Жуалынского района
Жамбыльской области
41
54
да
8.
Поставка и внедрение медицинской
информационной системы для
Городской поликлиники №7
г.Астаны
41
54
да
9.
Поставка и внедрение медицинской
информационной системы для
Городской больницы №1 г.Астаны
41
54
да
Раздел VI. Технические требования
222
Инвентаризационная таблица системы (Затраты на поставку и инсталляцию)
Система, подсистема и номер лота: лоты 1-9
Компонент
Компонент
No.
Соответствующая
техническая
спецификация
No.
Дополнительная
информация по месту
поставки (например:
здание, этаж, отдел, и т.д.)
Количество
1.
Поставка и внедрение медицинской информационной
системы для Усть-Каменогорской городской
больницы №1
1
2.
Поставка и внедрение медицинской информационной
системы для Городской клинической больницы №4 г.
Алматы
1
3.
Поставка и внедрение медицинской информационной
системы для Центра матери и ребенка г. УстьКаменогорск
1
4.
Поставка и внедрение медицинской информационной
системы для Городской поликлиники №11 г. Алматы
1
5.
Поставка и внедрение медицинской информационной
системы для Регионального диагностического центра
г. Алматы
1
6.
Поставка и внедрение медицинской информационной
системы для Поликлиники №1 г. Костанай
1
7.
Поставка и внедрение медицинской информационной
системы для Центральной районной больницы
Жуалынского района Жамбыльской области
1
Раздел VI. Технические требования
223
Компонент
Компонент
No.
Соответствующая
техническая
спецификация
No.
Дополнительная
информация по месту
поставки (например:
здание, этаж, отдел, и т.д.)
Количество
8.
Поставка и внедрение медицинской информационной
системы для Городской поликлиники №7 г.Астаны
1
9.
Поставка и внедрение медицинской информационной
системы для Городской больницы №1 г.Астаны
1
Раздел VI. Технические требования
224
Таблица мест поставки
Система, подсистема или номер лота: закупка всей Системы
Место поставки
Город/Регион
Адрес
Усть-Каменогорская городская
больница №1
ВКО, г. УстьКаменогорск
ул.Абая, 18
г. Алматы
Турксибский район, ул.
Папанина д.220
ВКО, г. УстьКаменогорск
ул.Утепова 35,37
№ места
поставки
1.
2.
Городская клиническая
больница №4 г. Алматы
3.
Центр матери и ребенка г.
Усть-Каменогорск
4.
Городская поликлиника №11
г.Алматы
г. Алматы
Жетысуский район, ул.
Жумабаева 87
5.
Региональный
диагностический центр
г.Алматы
г.Алматы
ул.Ауезова, 57
6.
Поликлиника №1 г.Костанай
Костанайская область,
г.Костанай
пр.Аль-Фараби 112
7.
Центральная районная
больница Жуалынского района
Жамбыльской области
Жамбылская область,
Жуалынский район, с. Б.
Момышулы, ул. С.Бейбарыс,
1
Ссылка на
чертеж No.
(если
требуется)
Раздел VI. Технические требования
Место поставки
225
Город/Регион
Адрес
№ места
поставки
8.
Городская поликлиника №7
г.Астаны
г.Астана
пр. Ш. Кудайбердыулы 25,29
9.
Городская больница №1
г.Астаны
г.Астана
пр. Кошкарбаева, 66
Ссылка на
чертеж No.
(если
требуется)
Раздел VI. Технические требования
226
Праздники и прочие не рабочие дни
Месяц
2015
2016
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
Раздел VI. Технические требования
227
G. КОНТРОЛЬНЫЙ СПИСОК ТЕХНИЧЕСКОГО СООТВЕТСТВИЯ
Примечание для участников: Следующий контрольный список поможет участникам торгов
организовать и последовательно представить свой технические предложения. Для каждого из
следующих технических требований, Участник торгов должен описать, как его техническое
предложение реагирует на каждое требование. Кроме того, Участник торгов должен представить
перекрестные ссылки на соответствующую вспомогательную информацию, если таковая имеется.
Перекрестные ссылки должны определить соответствующий документ (ы), номер страницы (ы), и
пункт (ы). Контрольный список технического соответствия не заменяет оставшуюся часть
Технических требований (или любой другой части тендерной документации). Если требование не
упоминается в Перечне, это не освобождает Участника от ответственности в том числе
подтверждения соблюдения этого требования. Ответов состоящих из одного или двух слов
(например, "Да", "Нет", "Будет соответствовать" и т.д.), как правило, не достаточно для
подтверждения
технического
соответствия
техническим
требованиям.
Раздел VI. Технические требования
228
Контрольный список технического соответствия
Номер
R1
Описание
Обязательное (M)/
Номер
Преимущественное
пункта
(D)
Общие Бизнес требования к Системе
R1.1
Механизм лицензирования для Системы в
рамках данного контракта предоставляет
право использовать все ее модули и
составные части в рамках Организации
для
количества
пользователей
достаточного
для
полноценного
функционирования
медицинской
организации (размер организации можно
оценить из описания в Приложении 2), в
течение
неограниченного
времени,
неограниченного количества серверов,
снимая
все
прочие
возможные
ограничения. Не допускаются ежегодные
лицензионные сборы; полная стоимость
лицензии включает в себя все расходы на
лицензирование Системы.
M
R1.2
В рамках данного Контракта должна быть
обеспечена
интероперабельность
M
Перекрестные
Расходы,
ссылки на
необходимые вспомогательную
для
информацию по
обеспечения
стоимости
технического
обеспечения
соответствия: технического
соответствия
Раздел VI. Технические требования
229
Системы с национальной системой
электронного здравоохранения согласно
требованиям
R7.
Общая
схема
взаимодействия с национальной системой
электронного
здравоохранения
представлена на Рисунке 1.
R1.3
Обобщенная архитектура комплексной
информационной
системы
здравоохранения,
которой
должна
соответствовать Система, представлена на
рисунке 2
M
R1.4
Модули и/или составные части системы
должны иметь возможность обмена
информацией между собой используя
http(s) -протокол
M
R1.5
Система
должна
иметь
SOAориентированную
архитектуру,
поддерживающую строго определенные и
платформо-независимые
интерфейсы
взаимодействия.
M
R1.6
По крайней мере следующий функционал,
рассчитанный на использование широким
кругом пользователей (пациенты, врачи
по удаленному доступу, руководители)
должен быть реализован в качестве webприложения:
- ведение демографических данных
пациента
M
Раздел VI. Технические требования
230
- ведение жалоб пациента
- ведение аллергологического анамнеза
- ведение анамнеза жизни
- ведение перенесенных заболеваний
ведение
анамнеза
настоящего
заболевания
- ведение объективный статус осмотра
пациента
- ведение локального статуса осмотра
пациента
- ведение информации о реакциях на
лекарственные препараты
- ведение направлений на лабораторные
исследования
- ведение врачебных назначений
ведение
направлений
на
консультативно-диагностические услуги
- просмотр результатов лабораторных
исследований
- просмотр результатов консультативнодиагностических услуг
ведение
проведенных
лечебных
мероприятий
- формирование отчетных форм
- ведение дополнительных записей врача
R1.7
Система
должна иметь способность
тонкой настройки, чтобы обеспечить
конфигурацию
под
потребности
конкретной
Организации
без
необходимости новой разработки (или
M
Раздел VI. Технические требования
231
включая малую доработку)
R1.8
Поставщик в рамках данного Контракта
должен обеспечить интероперабельность
Системы
с
Национальными
инструментами ЭПЗ (Репозиторий ЭПЗ,
Национальные
классификаторы
и
идентификаторы,
аналитическое
хранилище,
ЭПЗ-веб-сервисы)
в
соответствии с R7
M
R1.9
Должна быть обеспечена интеграция
Системы с внедренной бухгалтерской
системой «1C». Уровень интеграции
должен быть определен в ходе реализации
Контракта и согласован с организацией, в
которой
осуществляется
внедрение
Системы
M
R1.10
Система
должна
обеспечивать
конфиденциальность
персональных
данных в процессе сохранения и
передачи:
шифрование
конфиденциальных данных в базе
данных,
шифрование
данных
при
передаче через каналы, использование
безопасных протоколов передачи и т.д.
M
R1.11
Система
должна
обеспечивать
возможность использования электронноцифровой подписи для подписания и
аутентификации
электронных
M
Раздел VI. Технические требования
232
документов, файлов и частей документов.
Необходимость
использования
электронно-цифровой подписи должна
быть конфигурируемой
на
уровне
системного администратора.
Более
подробно о требованиях к электронной
подписи см. R5.15.
R1.12
Система
должна
быть
полностью
работоспособной и сдана Покупателю
«под ключ» в соответствии с R14.2. Для
выполнения
данного
требования,
Поставщик должен, при необходимости,
добавить
недостающие
части,
функциональность и технологические
решения,
включая
стоимость
отсутствующих
частей
в
таблице
стоимостей в раздел «другие»
M
R1.13
Поставщик должен обеспечить не менее
чем, но не ограничиваясь, следующее:
конфигурацию, развертывание, установку,
тестирование Системы и обучение
пользователей,
администраторов
(и
другого персонала при необходимости).
M
R1.14
Поставщик
должен
участвовать
в
процессе
сертификации
Системы
совместно с Поставщиком Платформы с
целью
проверки
и
сертификации
интероперабельности с национальными
ресурсами и инструментами ЭПЗ, в
M
Раздел VI. Технические требования
процедурах проведения
испытаний Системы
233
аттестации
и
R1.15
Поставщик
должен
обеспечить
гарантийное обслуживание Системы в
течение 3 лет со дня передачи системы в
эксплуатацию Покупателю в соответствии
с R12.4
M
R1.16
В случае если для полноценного
функционирования Системы «под ключ»
необходимо наличие дополнительного
лицензионного
программного
обеспечения,
Поставщик
обязан
обеспечить наличие всех лицензий за
свой счет и их передачу в собственность
Покупателя в рамках данного Контракта.
M
R1.17
Поставщик системы должен поставить в
Организации конфигурацию Системы
согласно Таблице 1. Составляющие
компоненты Системы уточнены в таблице
2.
M
R1.18
Минимальные требования для каждого
модуля
должны
соответствовать
требованиям раздела R2
M
R1.19
Поставщик в составе конкурсного
предложения в данном тендере должен
предоставить предлагаемую редакцию
технической
спецификации
с
M
Раздел VI. Технические требования
соблюдением формата
данного документа
234
и
структуры
R1.20
Система должна иметь возможности
интеграции со средами разработки (IDE),
как минимум для Java и Net Framework.
Система должна иметь в комплекте
средства разработки (SDK), включающий
в себя: документацию, примеры кода как
минимум для Java и Net Framework, для
конфигурирования функции Системы.
Должна быть возможность расширения
функциональности
Системы
с
ипользованием средств разработки (SDK),
входящих в состав Системы.
D
R1.21
Механизм лицензирования для Системы в
рамках данного контракта не должен
ограничивать изменения, вносимые с
помощью средств разработки (SDK),
входящих в состав Системы. Внесение
изменений с помощью средств разработки
(SDK), входящих в состав Системы, не
должно влиять на условия гарантийного
обслуживания
Системы.
Внесение
изменений в Систему специалистами
Заказчика допускается после сдачи
Системы в эксплуатацию.
M
R1.22
Поставщик
должен
обеспечить
обслуживание и техническую поддержку,
включая предоставление новых версий
M
Раздел VI. Технические требования
235
продуктов (согласно R12.3).
Время отклика сервисов и компонентов
Системы должно быть не более 3-5
секунд, для не менее 80% случаев ввода
данных или запросов на просмотр данных
(при скорости канала 1 Мб/с и времени
отклика не более 100 мс).
М
R1.25
Поставщик должен документировать и
передать
в
электронном
виде
конфигурационные файлы,и исходный
код,
компонентов
Системы,
разработанные
в
рамках
данного
контракта.
М
R1.26
Система должна иметь тонкий клиент, для
взаимодействия
с
оборудованием
допускается
использование
толстого
клиента.
R1.23
М
Система должна отвечать следующим
требованиям в отношении отчетности:
R1.27
 Все аналитические формы и
отчетные
формы
должны
иметь
возможность экспорта в форматы .xls,
xlsx, .docx, doc, .pdf, .csv, .html, .xml.
 Время
формирования
аналитических и отчетных форм не
должно превышать 1 мин. При этом для
M
Раздел VI. Технические требования
236
95 % случаев, время формирования
аналитических и отчетных форм не
должно превышать 30 секунд.
 В
системе
должно
быть
предусмотрена
возможность
формирования аналитических и отчетных
форм по расписанию.
 В
системе
должно
быть
предусмотрена возможность отправки
сформированной
аналитической
и
отчетной формы на указанный адрес
электронной почты.
R2
Требования
процессам
к
автоматизированным
R2.1
Модуль «1. Регистратура»
R2.1.1
Ведение графиков работы врачей,
выполнения услуг, работы аппаратов.
Данный процесс включает, как минимум:
М
R2.1.1.1
Создание графика работы врача с
возможностью выбора данных врача
(ФИО,
должность,
специальность,
структурное подразделение) из перечня
сотрудников данной организации.
M
R2.1.1.2
Проверка на наличие уже существующего
графика на данный промежуток времени
(дата, время), для данного врача,
M
Раздел VI. Технические требования
237
кабинета, аппарата и информирование
пользователя о его наличии при создании
графика работы врача, выполнения услуги
или работы аппарата
R2.1.1.3
Поиск графика среди существующих по
дате, времени, врачу, специальности
врача, услуге, аппарату и их сочетаниям
M
R2.1.1.4
При создании графика работы врача,
выполнения услуги или работы аппарата
возможность осуществлять привязку
врача, услуги и аппарата между собой.
Данная
привязка
не
является
обязательной к заполнению
M
R2.1.1.5
При создании графика выполнения услуги
возможность выбора услуг из перечня
услуг, на выполнение которых имеет
право Организация и специалист, ее
выполняющий
M
R2.1.1.6
При создании графика работы аппаратов
возможность выбора аппарата из перечня
аппаратов Организации
M
R2.1.1.7
Возможность создания, редактирования и
удаления графиков
M
R2.1.1.8
При удалении или редактировании
графиков при наличии уже записанных
пациентов возможность автоматического
M
Раздел VI. Технические требования
238
подбора
возможного
ближайшего
подходящего времени у аналогичного
специалиста и возможность выбора
определенного времени пользователем
R2.1.1.9
R2.1.1.10
При удалении или редактировании
графиков должна быть возможность
автоматического уведомления пациента
об изменившихся дате, времени, месте
приема по электронной почты и/или SMS
Формирование следующих отчетных
форм:
1.
Сводная информация о графиках
работы врачей, в разрезе подразделений,
смен,
выполнения
услуг,
работы
аппаратов.
2.
Отчет
пациентов
графиков.
M
M
об изменениях записи
вследствие
изменения
R2.1.2
Запись пациента на прием с выдачей
талона на прием. Данный процесс
включает, как минимум:
М
R2.1.2.1
Запись
пациента
сотрудником
регистратуры, врачом во время приема,
пациентом через Интернет с выдачей
талона на прием
M
Раздел VI. Технические требования
239
R2.1.2.2
Регистрация
новых
пациентов
с
заполнением персональных данных, в том
числе занесение данной информации из
ИС МЗСР РК
M
R2.1.2.3
Выбор пациента из базы данных
пациентов по ИИН или по ФИО, дате
рождения
M
R2.1.2.4
Печать маршрутного листа на выданные
талоны с указанием врача, кабинета, даты
и времени приема, при необходимости
указания дополнительной информации
(способа
подготовки
пациента
к
посещению и т.п.)
M
R2.1.2.5
Регистрация
выдачи
и
получения
амбулаторных карт пациентов
M
R2.1.2.6
Отмена
записи
сотрудником
регистратуры, врачом во время приема,
пациентом через Интернет
M
R2.1.2.7
Формирование «Листа ожидания» для
заполнения освободившегося в результате
отмены записи времени приема с
автоматическим уведомлением пациента в
случае его записи на освободившееся
время приема посредством электронной
почты и/или SMS
M
R2.1.2.8
Возможность
M
бронирования
времени
Раздел VI. Технические требования
240
приема в графике (одиночное, групповое)
с регулируемым временем снятия брони
R2.1.2.9
Автоматическое предотвращение записи
пациента к нескольким специалистам в
одно и тоже время приема, а также
предотвращение
записи
нескольких
пациентов в одно и тоже время к одному
специалисту
M
R2.1.2.10
Поиск времени для записи среди
существующих
графиков
по
дате,
времени, врачу, специальности, услуге,
аппарату и их сочетаниям
M
Формирование следующих отчетных
форм:
1. Отчет о количестве записанных на
прием (по врачу, услуге, аппарату,
отделению, Организации)
R2.1.2.11
2. Отчет о количестве свободных
мест (по врачу, услуге, аппарату,
отделению, Организации)
3. Отчет об отмененных визитах
4. Отчет о неявившихся пациентах
5. Отчет о бронировании посещений
6. Отчет по обратившимся пациентам
(за отчетный период, в разрезе
M
Раздел VI. Технические требования
241
направивших МО, в разрезе
специалистов, в разрезе услуг)
R2.1.3
Ведение журнала вызовов на дом. Данный
процесс включает, как минимум:
M
R2.1.3.1
Регистрация вызова на дом, принятого по
телефону, посредством Интернет и при
обращений пациента в МО
M
R2.1.3.2
Регистрация отмены вызова на дом по
инициативе пациента
M
R2.1.3.3
Регистрация передачи врачу вызова на
дом
M
R2.1.3.4
Регистрация факта выполнения вызова на
дом с детализацией результатов вызова
M
R2.1.3.5
Регистрация необходимости повторного
вызова и его даты
M
R2.1.3.6
Формирование листа нераспределенных
вызовов: в разрезе участков, по
организации в целом
M
R2.1.3.7
Формирование
листа
вызовов
для
исполнения врачом с указанием ФИО
пациента, диагноза, адреса, телефона,
примечаний
M
R2.1.3.8
Формирование
M
следующих
отчетных
Раздел VI. Технические требования
242
форм:
1. Отчет о вызовах на дом (открытых,
принятых,
исполненных,
отмененных) по врачу, пациенту,
участку
2. Отчет о времени поступления и
выполнения вызовов
R2.1.4
Ведение журнала активов (вызовы на дом
по инициативе медицинских работников).
Данный процесс включает, как минимум:
M
R2.1.4.1
Разделение активов на группы – активы
стационара, активы поликлиники, активы
новорожденных, активы скорой, активы
беременных, родильниц
M
R2.1.4.2
Регистрация актива, принятого
телефону, через Интернет
M
R2.1.4.3
Регистрация группы активов путем
импорта файла – таблицы установленного
образца
M
R2.1.4.4
Регистрация отмены актива
M
R2.1.4.5
Регистрация передачи актива врачу
M
R2.1.4.6
Регистрация факта выполнения актива с
детализацией результатов актива
M
по
Раздел VI. Технические требования
243
R2.1.4.7
Регистрация необходимости повторного
актива и его даты
M
R2.1.4.8
Формирование листа нераспределенных
активов
в
разрезе
участков,
по
организации в целом
M
R2.1.4.9
Формирование
листа
активов
для
исполнения врачом с указанием ФИО
пациента, диагноза, адреса, телефона,
примечаний
M
R2.1.4.10
Формирование следующих отчетных
форм:
1. Отчет об активах (открытых,
принятых,
исполненных,
отмененных) по врачу, пациенту,
участку
M
2. Отчет о времени регистрации и
выполнения активов
R2.1.5
Ведение
первичной
учетной
документации на уровне регистратуры в
соответствии
с
действующими
нормативными правовыми актами РК.
Данный процесс включает, как минимум
ведение следующих учетных форм:
M
R2.1.5.1
Форма 040/у
Форма 025-4/ у
M
Раздел VI. Технические требования
244
Форма 025-9/у
Форма 025-5/у
Форма 031/у
R2.1.6
Формирование аналитических форм на
уровне
регистратуры,
а
также
статистических таблиц в соответствии с
действующими
нормативными
правовыми актами РК.
M
R2.1.7
Взаимодействие с ИС МЗСР РК. Данный
процесс включает, как минимум:
M
R2.1.7.1
Передача информации о графиках приема
врачей, выполнения услуги, работы
аппаратов.
M
R2.1.8
Регистрация
фактов
прикрепления/
открепленния обслуживаемого населения
медицинской организации.
M
R2.2
Модуль «2. Участковый врач»
R2.2.1
Ведение амбулаторной карты пациента.
Данный процесс включает, как минимум:
М
R2.2.1.1
Просмотр
списка
записавшихся на прием
M
R2.2.1.2
Создание амбулаторной карты пациента
M
R2.2.1.3
Создание и редактирование шаблонов в
M
пациентов,
Раздел VI. Технические требования
245
том числе формирование медицинских
документов и записей, консультаций,
протоколов
осмотров,
дневниковых
записей с помощью шаблонов и
возможностью прикрепления файлов
(изображений, видеозаписи, звукозаписи)
с привязкой пользовательских шаблонов к
учетной записи пользователя
R2.2.1.4
Создание медицинских записей на основе
стандартных
или
пользовательских
шаблонов
M
R2.2.1.5
Редактирование и удаление медицинских
записей, подписанных ЭЦП, должно быть
заблокировано
M
R2.2.1.6
Вывод
на
печать
заполненных
медицинских записей для формирования
бумажной версии амбулаторной карты
M
R2.2.1.7
Возможность
выборки
медицинских
записей по определенному признаку
(посещения,
диагнозы,
даты,
диагностические
исследования,
лабораторные анализы, услуги, источники
финансирования и т.д.)
M
R2.2.1.8
Отчетная форма об изменении числовых
показателей
пациента
во
времени
(антропометрические
показатели,
функциональные
показатели,
M
Раздел VI. Технические требования
246
лабораторные данные и т.д.)
R2.2.2
Создание
направлений
на
консультативно-диагностические услуги
внутренние
(в
пределах
данной
организации) и внешние (в другие
медицинские
организации).
Данный
процесс включает, как минимум:
M
R2.2.2.1
Создание направления на КДУ внутри
организации с возможностью записи на
определенное время
M
R2.2.2.2
Создание направления на КДУ в иные
медицинские
организации
с
возможностью записи на определенное
время
M
R2.2.2.3
Согласование направлений на отдельные
виды услуг с заведующим отделением
M
R2.2.2.4
Формирование
рекомендаций
по
подготовке к КДУ на основе стандартных
шаблонов
M
R2.2.2.5
Удаление направлений (некорректных, по
инициативе пациента, автоматическое при
неявке пациента)
M
R2.2.2.6
Мониторинг
исполнения
клиникодиагностических
услуг
назначенных
пациенту, просмотр данных о выполнении
M
Раздел VI. Технические требования
247
назначения, включая результаты.
R2.2.2.7
R2.2.2.8
Согласование и отклонение заявок на
дополнительные КДУ
M
Формирование отчетных форм:
1. Отчет о созданных направлениях
(внутренние, внешние) по услугам,
источникам финансирования, по
уровням оказания медицинской
помощи
(районный,
областной/городской,
республиканский)
2. Пофамильный
список
направленных на консультативнодиагностическую помощь
M
3. Отчет о направлениях (открытые,
выполняющиеся,
выполненные,
отклоненные,
внешние,
внутренние)
R2.2.3
Оформление плановой госпитализации
(круглосуточный
стационар
и
стационарозамещающие
технологии).
Данный процесс включает, как минимум:
M
R2.2.3.1
Формирование выписки из медицинской
карты амбулаторного больного (форма
M
Раздел VI. Технические требования
248
027/у)
R2.2.3.2
Формирование:
- шаблонов по минимальным стандартам
исследований на догоспитальным этапам
по уровням МО
- направлении и талона на плановую
госпитализацию
M
R2.2.4
Формирование врачебных назначений
лекарственных средств и/или процедур и
манипуляций. Данный процесс включает,
как минимум:
M
R2.2.4.1
Создание рецептов на лекарственные
средства (платные, бесплатные, льготные)
и по наркотическим средствам с
ограниченным доступом определенной
категории врачей и с описанием способов
приема, дозировок и т.д.
M
R2.2.4.2
Контроль назначений в соответствии с
установленными
максимальными
разовыми дозами в зависимости от
возраста, пола, веса и т.д.
M
R2.2.4.3
Контроль назначений в соответствии с
формуляром Организации и Республики
Казахстан.
Результаты
обеспечения
льготными лекарственными препаратами
диспансерных
больных
и
других
категорий граждан
M
Раздел VI. Технические требования
249
R2.2.4.4
Подписание рецептов с помощью ЭЦП
M
R2.2.4.5
Проверка
наличия
лекарственного
препарата в аптеке. Данное требование
должно
быть
реализовано
путем
взаимодействия с модулем «Аптека»
M
R2.2.4.6
Создание направлений на выполнение
процедур с указанием лекарственных
средств и их дозировкой
M
R2.2.4.7
Формирование
рекомендаций
по
подготовке к процедурам на основе
стандартных шаблонов
M
R2.2.4.8
Контроль за выполнением назначений и
отпуском лекарственных препаратов
M
R2.2.4.9
Предоставление справочной информации
по
рекомендуемым
назначениям,
согласно утвержденных клинических
руководств и протоколов диагностики и
лечения
M
R2.2.4.10
Формирование
листа
назначений (форма 004-1/у)
M
R2.2.4.11
Формирование отчетных форм:
1. Отчет о созданных рецептах (МНН,
форма, дозировка, способ приема и
т.д.)
врачебных
M
Раздел VI. Технические требования
250
2. Пофамильный список получивших
рецепты
3. Пофамильный список получивших
рецепты, по льготным категориям
R2.2.5
Ведение
первичной
учетной
документации на уровне участкового
врача в соответствии с действующими
нормативными правовыми актами РК.
Данный процесс включает, как минимум
ведение следующих форм:
M
R2.2.5.1
001-2/у, 001-3/у, 001-4/у, 001-5/у, 001-6/у,
003-2/у, 004-1/у, 025/у (025-3, 025-4), 0253/у, 025-5/у, 025-7/у, 025-8/у, 026/у,
026-1/у, 026-2/у, 030/у, 032/у, 036/у, 038/у,
039/у, 040/у,
052/у, 053/у, 054/у, 058/у, 060/у, 063/у,
064/у, 070/у, 072/у, 075/у,
086/у, 088/у 088-1/у, 094/у, 095/у, 106/у12, 106-2/у-12, 112/у, 130/у,
132/у, 133/у, 138/у, 278/у, ТБ 15/у, ТБ
05/у,
M
R2.2.6
Формирование аналитических форм на
уровне участкового врача, а также
статистических таблиц в соответствии с
нормативно-правовыми актами. Данный
процесс
включает,
как
минимум
следующие формы отчетных форм:
M
Раздел VI. Технические требования
251
1. Ведомость учета посещений в
поликлинике
(амбулатории),
диспансере, консультации и на
дому (039/у), в том числе и в
разрезе участковых врачей ПМСП
2. Отчет о выполнении скрининговых
обследований согласно приказа МЗ
РК № 685от 10 ноября 2009 года, в
том числе и в разрезе участковых
врачей ПМСП
R2.2.7
3. Мониторинг
выполнения
обязательных
ежегодных
флюорографических обследований
населения, в том числе и в разрезе
участковых врачей ПМСП
4. Мониторинг
выполнения
ежемесячных т ежегодных планов
по иммунопрофилактике форма
№5, 6 приказ МЗ РК 128 от 06
марта 2013 года, в том числе и в
разрезе участковых врачей ПМСП
5. Отчет
о
поствакциональных
осложнениях в разрезе участковых
врачей по видам проф. прививок,
по возрастам и исходам, в том
M
Раздел VI. Технические требования
числе и в разрезе участковых
врачей ПМСП
6. Отчет о движении диспансерных
больных, в том числе и в разрезе
участковых врачей ПМСП
7. Отчет о движение диспансерных
больных с ХПН с указанием о
проведении
заместительной
терапии
(гемодиалиаз
или
перитонеальный, трансплантация
почки и др.), в том числе и в
разрезе участковых врачей ПМСП
8. Отчет о рождаемости, в том числе
и в разрезе участковых врачей
ПМСП
9. Отчет о смертности, в том числе и
в разрезе участковых врачей
ПМСП
10. Отчет об инвалидности, в том
числе и в разрезе участковых
врачей ПМСП
11. Отчет
о
направлении
и
госпитализации, в том числе
плановой госпитализации в разрезе
252
Раздел VI. Технические требования
участковых врачей ПМСП
12. Отчет по мероприятиям ЗОЖ, в
том числе и в разрезе участковых
врачей ПМСП
13. Отчет о количестве и структуре
прикрепленного населения, в том
числе и в разрезе участковых
врачей ПМСП
14. Отчет о числе заболеваний,
зарегистрированнных у больных,
проживающих
в
районе
обслуживания
медицинской
организации
и
контингентах
больных,
состоящих
под
диспансерным
наблюдением
(форма 56, 12), в том числе и в
разрезе участковых врачей ПМСП
15. Отчет о контингентах больных,
получивших
стационарозамещающую помощь
(форма 24), в том числе и в разрезе
участковых врачей ПМСП
16. Отчет о медицинской помощи
детям (форма 31), в том числе и в
разрезе участковых врачей ПМСП
253
Раздел VI. Технические требования
254
17. Отчет по детской инвалидности
(форма 52), в том числе и в разрезе
участковых врачей ПМСП
18. Отчет об использовании коечного
фонда медицинских организаций,
оказывающих стационарную и
стационарозамещающую помощь
(форма 21), в том числе и в разрезе
участковых врачей ПМСП
19. Отчет о доставленных пациентов
скорой медицинской помощи, в
том числе и в разрезе участковых
врачей ПМСП
R2.2.8
Ведение
учета
листов
временной
нетрудоспособности. Данный процесс
включает, как минимум:
M
R2.2.8.1
Регистрация
листа
нетрудоспособности
временной
M
R2.2.8.2
Продление
листа
нетрудоспособности
временной
R2.2.8.3
Закрытие
листа
нетрудоспособности
временной
R2.2.8.4
Отправка
листа
временной
нетрудоспособности на согласование с
M
M
M
Раздел VI. Технические требования
255
заведующим отделением или с ВКК
R2.2.8.5
R2.2.8.6
Формирование
(форма 088/у)
направления
на
МСЭ
Формирование отчетных форм:
1. Отчет
о
выданных
листах
временной нетрудоспособности
M
M
2. Отчет о направленных на МСЭ
R2.2.9
Взаимодействие с ИС МЗСР РК. Данный
процесс включает, как минимум:
M
R2.2.9.1
Обмен информацией в соответствии с
требованиями стандартов ЭПЗ и ЭМЗ.
Подробнее см. R7.2.1.
M
R2.2.9.2
Обмен информацией о госпитализации
M
R2.2.9.3
Обмен информацией
услугах
M
R2.2.9.4
Обмен
клинической
информацией
(заключительные диагнозы, результаты
консультаций, осмотров и т.д.)
M
R2.2.9.5
Обмен информацией о направлениях на
КДУ
M
R2.2.9.6
Обмен информацией
процедур
M
о
о
выполненных
назначениях
Раздел VI. Технические требования
256
R2.2.9.7
Обмен информацией о рецептах
R2.3
Модуль «3 Ведение профилактических
осмотров»
R2.3.1
Формирование контингентов подлежащих
профилактическим осмотрам целевых
групп населения (скрининг) и учет их
проведения
в
соответствии
с
действующими
нормативными
правовыми актами РК Данный процесс
включает, как минимум:
М
R2.3.1.1
Формирование пофамильных списков для
прохождения профилактических осмотров
целевых групп населения (скринингов) из
числа прикрепленного населения в
соответствии
с
требованиями
нормативно-правовых актов
M
R2.3.1.2
Возможность
автоматического
уведомления пациентов (посредством
электронной почты и/или SMS) о
необходимости
прохождения
скрининговых осмотров
M
R2.3.1.3
Формирование маршрутных листов для
прохождения скринингов
M
R2.3.1.4
Отметка о выполнении исследований в
рамках
скринингов
с
указанием
результата и/или заключения
M
M
Раздел VI. Технические требования
257
R2.3.1.5
Автоматическое
формирование
направлений к специалистам в рамках
прохождения скрининга
M
R2.3.1.6
Заполнение карты скринингового осмотра
M
R2.3.1.7
Формирование
заключения
прохождении скрининга
M
R2.3.1.8
о
Формирование отчетных форм:
1. Отчет о контингентах подлежащих
скрининговому осмотру (по видам
скрининга, участку, возрастнополовой структуре)
M
2. Отчет о прохождении скринингов
3. Отчет о заболеваниях, выявленных
в ходе скрининга
R2.3.2
Учет других видов профилактических
осмотров периодических и очередных при
устройстве на работу. Данный процесс
включает, как минимум:
M
R2.3.2.1
Формирование пофамильных списков для
прохождения профилактических осмотров
M
R2.3.2.2
Формирование маршрутных листов для
прохождения профилактических осмотров
M
Раздел VI. Технические требования
258
R2.3.2.3
Отметка о выполнении исследований в
рамках профилактических осмотров с
указанием результата и/или заключения
M
R2.3.2.4
Автоматическое
формирование
направлений к специалистам в рамках
прохождения профилактических осмотров
M
R2.3.2.5
Заполнение
осмотра
M
R2.3.2.6
Формирование
заключения
о
прохождении профилактического осмотра
с выдачей справки
карты
профилактического
M
Формирование отчетных форм:
1. Отчет
о
выполненных
профилактических осмотрах (по
видам
скрининга,
участку,
возрастно-половой структуре)
R2.3.2.7
2. Отчет о заболеваниях, выявленных
на профилактическом осмотре
M
3. Отчет о контигентах, подлежащих
периодическим профилактическим
осмотрам
R2.3.3
Ведение
первичной
учетной
документации на уровне врача в
соответствии
с
действующими
M
Раздел VI. Технические требования
259
нормативными правовыми актами РК
Данный процесс включает, как минимум
ведение следующих учетных форм:
R2.3.3.1
025/у, 025-4/у, 025-5/у, 025-7/у, 025-8/у,
030/у, 032/ у, 040/у, 086/у, 108/у, 108-1/у,
112/у, 131/у, 245/у
R2.4
Модуль «4. Профильный специалист»
R2.4.1
Создание и ведение амбулаторной карты
пациента с использованием данных
национального ЭПЗ. Данный процесс
включает, как минимум:
М
R2.4.1.1
Просмотр
списка
записавшихся на прием
M
R2.4.1.2
Создание и редактирование шаблонов в
том числе формирование медицинских
документов и записей, консультаций,
протоколов
осмотров,
дневниковых
записей с помощью шаблонов и
возможностью прикрепления файлов
(изображений, видеозаписи, звукозаписи)
с привязкой пользовательских шаблонов к
учетной записи
M
R2.4.1.3
Создание медицинских записей на основе
стандартных
или
пользовательских
шаблонов
M
пациентов,
M
Раздел VI. Технические требования
260
R2.4.1.4
Редактирование и удаление медицинских
записей, находящихся в неподписанном
виде
M
R2.4.1.5
Вывод
на
печать
заполненных
медицинских записей для формирования
бумажной версии амбулаторной карты
M
R2.4.1.6
Возможность
выборки
медицинских
записей по определенному признаку
(посещения,
диагнозы,
даты,
диагностические
исследования,
лабораторные анализы, услуги, источники
финансирования и т.д.)
M
R2.4.1.7
Отчет
об
изменении
числовых
показателей
пациента
во
времени
(антропометрические
показатели,
функциональные
показатели,
лабораторные данные и т.д.)
M
R2.4.2
Создание направлений на внутренние (в
пределах
данной
медицинской
организации) и внешние (в другие
медицинские организации) КДУ. Данный
процесс включает, как минимум:
M
R2.4.2.1
Создание
направления
на
дополнительные
КДУ
в
рамках
направления из подразделения ПСМП
внутри организации с возможностью
записи на определенное время
M
Раздел VI. Технические требования
261
R2.4.2.2
Добавление дополнительных КДУ без
согласования с подразделением ПМСП
M
R2.4.2.3
Создание заявки на дополнительные виды
исследований
для
согласования
с
подразделением ПМСП
M
R2.4.2.4
Отметка о выполнении КДУ
M
R2.4.2.5
Формирование протокола консультации,
осмотра,
операции
на
основании
стандартных
и
пользовательских
шаблонов
M
R2.4.2.6
Формирование
рекомендаций
по
подготовке к КДУ на основе стандартных
шаблонов
M
R2.4.2.7
Удаление направлений (некорректных, по
инициативе пациента, автоматическое при
неявке пациента)
M
R2.4.2.8
Контроль
за
исполнением
КДУ.
Регистрация
впервые
выявленного
диспансерного больного и передача
сведений
для
участкового
врача,
рекомендации
по
периодичности
наблюдения и обследования
M
R2.4.2.9
Формирование отчетных форм:
1. Отчет о созданных направлениях
(внутренние, внешние) по услугам,
M
Раздел VI. Технические требования
262
источникам финансирования
2. Пофамильный
список
направленных на консультативнодиагностическую помощь
3. Отчет о выполненных КДУ
4. Пофамильный список пациентов,
получивших КДУ
R2.4.3
Формирование врачебных назначений
лекарственных средств и/или процедур и
манипуляций. Данный процесс включает,
как минимум:
M
R2.4.3.1
Создание рецептов на лекарственные
средства
(платные,
бесплатные)
с
описанием способов приема, дозировок и
т.д.
M
R2.4.3.2
Контроль назначений в соответствии с
установленными
максимальными
разовыми дозами в зависимости от
возраста, пола, веса и т.д.
M
R2.4.3.3
Контроль назначений в соответствии с
формуляром Организации и Республики
Казахстан
M
R2.4.3.4
Подписание рецептов с помощью ЭЦП
M
Раздел VI. Технические требования
263
R2.4.3.5
Проверка
наличия
препарата в аптеке
лекарственного
R2.4.3.6
Создание направлений на выполнение
процедур
M
R2.4.3.7
Формирование
рекомендаций
по
подготовке к процедурам на основе
стандартных шаблонов.
M
R2.4.3.8
Контроль за выполнением назначений и
отпуском лекарственных препаратов
M
R2.4.3.9
Предоставление
рекомендуемых
назначений
согласно
утвержденных
клинических руководств и протоколов
диагностики и лечения
M
M
Формирование отчетных форм:
1. Отчет о созданных рецептах
(МНН, форма, дозировка, способ
приема и т.д.)
R2.4.3.10
2. Пофамильный список назначенных
и получивших рецепты
3. Пофамильный список назначенных
и получивших льготные рецепты
4. Пофамильный список назначенных
и получивших ИМН
5. Пофамильный
список
M
Раздел VI. Технические требования
264
направленных на консультативнодиагностическую помощь
6. Отчет
о
направлениях
на
процедуры
(открытые,
выполняющиеся,
выполненные,
откроленные,
внешние,
внутренние)
R2.4.4
Ведение
первичной
учетной
документации на уровне профильного
специалиста
в
соответствии
с
действующими
нормативными
правовыми актами РК. Данный процесс
включает,
как
минимум
ведение
следующих учетных форм:
M
R2.4.5
001-3/у, 001-4/у, 001-5/у, 001-6/у, 007-1/у,
025/у, 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/у, 0392/у, 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/у,
M
Раздел VI. Технические требования
265
R2.4.6
Ведение
учета
листов
временной
нетрудоспособности. Данный процесс
включает, как минимум:
M
R2.4.7
Регистрация
листа
нетрудоспособности
временной
M
R2.4.7.1
Продление
листа
нетрудоспособности
временной
R2.4.7.2
Закрытие
листа
нетрудоспособности
временной
R2.4.7.3
Отправка
листа
временной
нетрудоспособности на согласование с
заведующим отделением или с ВКК.
M
R2.4.7.4
Формирование отчета о выданных листах
временной нетрудоспособности
M
R2.4.7.5
Формирование
направления
на
медицинскую
социально-экспертную
коммисию
(МСЭК),
создание
и
редактирование шаблонов для МСЭК
M
R2.4.8
Формирование аналитических форм на
уровне профильного специалиста, а также
статистических таблиц в соответствии с
действующими
нормативными
правовыми актами РК. Данный процесс
включает, как минимум:
M
M
M
Раздел VI. Технические требования
266
1. Ведомость учета посещений в
поликлинике
(амбулатории),
диспансере, консультации и на
дому (039/у)
2. Отчет о выполнении скрининговых
обследований согласно приказа МЗ
РК № 685от 10 ноября 2009 года
3. Отчет о движении диспансерных
больных
4. Отчет об инвалидности
5. Отчет о взрослой инвалидности
R2.4.8.1
6. Отчет о плановой госпитализации
7. Отчет о числе заболеваний,
зарегистрированнных у больных,
проживающих
в
районе
обслуживания
медицинской
организации
и
контингентах
больных,
состоящих
под
диспансерным
наблюдением
(форма 56, 12)
8. Отчет о контингентах больных,
получивших
стационарозамещающую помощь
(форма 24)
9. Отчет о медицинской помощи
M
Раздел VI. Технические требования
267
детям (форма 31)
10. Отчет по детской инвалидности
(форма 52)
11. Отчет об использовании коечного
фонда медицинских организаций,
оказывающих стационарную и
стационарозамещающую помощь
(форма 21)
R2.5
Модуль «5. Заведующий
поликлиники»
отделением
R2.5.1
Подтверждение
или
отклонение
направлений на отдельные виды услуг с
использованием ЭЦП.
М
R2.5.2
Ведение и согласование первичной
учетной
документации
на
уровне
заведующего отделением в соответствии с
действующими
нормативными
правовыми актами РК. Данный процесс
включает,
как
минимум
ведение
следующих учетных форм:
М
1. 035/у
2. 035-1/у
R2.5.2.1
3. 035-2/у
4. 035-3/у
M
Раздел VI. Технические требования
268
5. 095/у
6. 094/у
R2.5.3
Формирование аналитических форм на
уровне заведующего отделением, а также
статистических таблиц в соответствии с
действующими
нормативными
правовыми актами РК. Данный процесс
включает, как минимум:
М
Формирование отчетных форм:
1. Формирование
аналитических
форм
в
разрезах
аналогичных
таблицам сотрудников отделения
10. Отчет о прикрепленном населении
по участкам
R.2.6.3.1
11. Отчет о половозрастной структуре
прикрепленного населения
12. Отчет
о
кадровом
участковой службы
составе
13. Отчет по основным индикаторам
деятельности участков
14. Форма 12
15. Отчет по структуре посещений (в
разрезе
заболевании,
M
Раздел VI. Технические требования
269
профилактических
скринингов,
диспансерных больных, по визитам на
приеме, на дому, оказания СЗТ, визиты
к среднему медицинскому персоналу,
в доврачебный кабинет, процедурный
кабинет, на профпрививки)
16. Отчет по госпитализациям жителей
прикрепленного населения
17. Структура
консультативных
приемов по профильным специалистам
в разрезе участков прикрепленного
населения
R2.5.4
Согласование
листа
временной
нетрудоспособности, ведение записей
ВКК. Данный процесс включает, как
минимум :
М
R2.5.4.1
Согласование
длительных
нетрудоспособности
M
R2.5.4.2
Создание записей заседаний ВКК
M
R2.5.4.3
Формирование заключений ВКК
M
R2.5.4.4
Подпись заключений ВКК с помощью
ЭЦП
M
листов
Раздел VI. Технические требования
270
R2.5.4.5
Формирование отчетных форм:
1. Отчет о выданных листах временной
нетрудоспособности
2. Отчет о количестве лиц прошедших
через ВКК
3. Отчет о числе лиц направленных на
переосвидетельствование в МСЭ
R2.6
Модуль «6. Медицинская
поликлиники»
R2.6.1
Мониторинг ведения первичной учетной
документации в Организации
M
R2.6.2
Формирование аналитических форм на
уровне специалиста по медицинской
статистике, а также статистических
таблиц в соответствии с действующими
нормативными правовыми актами РК.
Данный процесс включает, как минимум:
M
R2.6.2.1
Конструктор
отчетных
форм
с
возможностью создания новых отчетных
форм и редактирования имеющихся
M
M
статистика
Формирование отчетных форм:
1. Форма 039/у
R2.6.2.2
2. Форма 007/у
3. Отчет о прикрепленном населении
и его половозрастной структуре
M
Раздел VI. Технические требования
271
4. Отчет о выполнении скрининговых
обследований
5. Отчет о кадровом составе участков
6. Отчет о работах по прикреплению
населения
7. Отчетные формы 21, 12, 17, 24, 30,
31, 32, 43, 47, 52, 59, 4, 5, 6, 56, 58
R2.7
Модуль «7. Приемный покой»
R2.7.1
Регистрация
обращений
пациентов.
Данный процесс включает, как минимум:
М
R2.7.1.1
Уточнение
пациента
M
R2.7.1.2
Проверка и ввод данных о категории
страховки и оплаты пациента
M
R2.7.1.3
Регистрация медицинского направления
и/или отказа в оказании медицинской
помощи
M
R2.7.1.4
Оформление
документов
M
R2.7.1.5
Установление
направлений
демографических
и
выдача
связи
данных
медицинских
между
дублями
M
Раздел VI. Технические требования
272
R2.7.1.6
Распределение
пациентов
специализированным
отделениям
палатам
R2.7.1.7
Предварительное прикрепление пациента
к лечащему врачу
M
R2.7.1.8
Подтверждение
больного
M
R2.7.2
Ведение ЭМЗ пациента. Данный процесс
включает, как минимум:
M
R2.7.2.1
Полное описание процессов и требований
ведения ЭМЗ выполняется в соответствии
с национальным стандартом Электронной
медицинской записи. (Утвержденный
Приказом и.о. Министра здравоохранения
№75 от 10.02.2014 г «Об утверждении
технической документации по вопросам
электронного здравоохранения»)
M
R2.7.2.2
Из тех данных, которые введены в ЭМЗ,
минимальный
обязательный
набор
данных передается в национальный ЭПЗ в
соответствии с национальным стандартом
Электронного паспорта здоровья
M
R2.7.3
Уточнение услуг, выполненных до
госпитализации.
Данный
процесс
включает, как минимум:
M
готовности
по
и
принять
M
Раздел VI. Технические требования
273
R2.7.3.1
Просмотр
ЭПЗ
пациента
национального Репозитория ЭПЗ
из
R2.7.3.2
Регистрация
диагнозов,
процедур,
назначений
и
других
данных
о
медицинских услугах, выполненных до
госпитализации, но не введенных в
системе
M
R2.7.4
Ведение
первичной
документации
таблиц
на
приемного покоя. Данный
включает,
как
минимум
следующих учетных форм:
M
R2.7.4.1
001/у, 003/у, 004-1/у, 045/у, 058/у, 060/у,
069/у, 264/у
M
R2.7.5
Формирование аналитических форм на
уровне приемного покоя. Данный процесс
включает, как минимум:
M
учетной
уровне
процесс
ведение
M
Формирование отчетных форм:
1.
Отчет о количестве проведенных
услуг, манипуляций, обследований
R2.7.5.1
2.
Отчет
вакцинам
по
медикаментам
и
3.
Отчет о проделанной работе (колво обратившихся больных, количество
госпитализированных в круглосуточный
M
Раздел VI. Технические требования
274
стационар в плановом и экстренном
порядке, в дневной стационар, количество
отказов от госпитализации, кол-во
доставленных
по
скорой
помощи,
направлено
из
ПМСП
или
самообращение)
4.
Отчет об активах, переданных в
поликлинику
5.
Формирование
таблицы
сети
коечного фонда МО с указанием
свободных
R2.7.6
Взаимодействие с ИС МЗСР РК. Данный
процесс включает, как минимум:
M
R2.7.6.1
Обмен
информацией
об
услугах
оказанных в приемном покое до
госпитализации
M
R2.7.6.2
Обмен информацией о госпитализации и
отказах госпитализации
M
R2.7.6.3
Обмен
информацией
коечного фонда
M
R2.7.6.4
Обмен данными с ИС МЗСР РК в
соответствии
с
требованиями
интероперабельности МЗСР РК
о
состоянии
M
Раздел VI. Технические требования
275
R2.8
Модуль «8. Врач стационара»
R2.8.1
Ведение ЭМЗ пациента. Данный процесс
включает, как минимум:
М
R2.8.1.1
Полное описание процессов и требований
ведения ЭМЗ выполняется в соответствии
с национальным стандартом Электронной
медицинской записи. (Утвержденный
Приказом и.о. Министра здравоохранения
№75 от 10.02.2014 г «Об утверждении
технической документации по вопросам
электронного здравоохранения»)
M
R2.8.1.2
Из тех данных, которые введены в ЭМЗ,
минимальный
обязательный
набор
данных передается в национальный ЭПЗ в
соответствии с национальным стандартом
Электронного паспорта здоровья
M
R2.8.1.3
Формирование истории болезни, на
основе стандартного шаблона для
соответствующего
коечного
фонда
(персональные
данные,
анамнез
заболевания,
анамнез
жизни,
перенесенные заболевания, результаты
первичного осмотра, назначения)
M
R2.8.1.4
Составление предварительного плана
лечения
и
при
необходимости
дополнительных исследований
M
Раздел VI. Технические требования
276
R2.8.1.5
Регистрация ежедневных осмотров и
результатов
обследований
больного
лечащим врачом
M
R2.8.2
Ведение направлений на КДУ. Данный
процесс включает, как минимум:
M
R2.8.2.1
Уточнение плана лечения, использование
плана во время лечения пациента,
изменение плана при необходимости.
M
R2.8.2.2
Формирование
направлений
на
лабораторные исследования, изучение
результатов и (при необходимости)
написание интерпретаций
M
R2.8.2.3
Формирование
направлений
на
диагностические исследования, изучение
результатов и написание интерпретаций
M
R2.8.2.4
Формирование
консультации
специалистам,
специалистов
M
R2.8.2.5
Мониторинг состояния направлений и
определение опозданий и отказов
M
R2.8.3
Постановка диагноза. Данный процесс
включает, как минимум:
M
R2.8.3.1
Просмотр
истории
национального ЭПЗ
M
направлений
на
к
другим
врачамизучение
заключений
болезни
из
Раздел VI. Технические требования
277
R2.8.3.2
Просмотр результатов анализов
M
R2.8.3.3
Уточнение и регистрация диагнозов:
диагноз
направившей
организации
(направительный),
диагноз
при
поступлении
(предварительный),
заключительный клинический диагноз,
осложнения, сопутствующие заболевания,
окончательный, патологоанатомический
диагноз
M
R2.8.3.4
Мониторинг выполнения плана лечения и
его уточнение
M
R2.8.4
Формирование врачебных назначений
лекарственных средств и/или процедур и
манипуляций. Данный процесс включает,
как минимум:
M
R2.8.4.1
Данные
пациента
M
R2.8.4.2
Проверка совместимости лекарств
M
R2.8.4.3
Формирование назначений больным по
приему лекарств
M
R2.8.4.4
Назначение лечебных и диагностических
процедур
M
R2.8.4.5
Мониторинг
правильности
и
своевременности выполнения назначений
M
аллергического
анамнеза
Раздел VI. Технические требования
278
со стороны медицинской сестры
вовлеченных участников лечения
и
R2.8.4.6
Регистрация фактов побочного действия и
осложнений лекарств и процедур
M
R2.8.5
Выписка пациента. Данный
включает, как минимум:
M
R2.8.5.1
Определение окончательного диагноза
M
R2.8.5.2
Составление формы 066/у
M
R2.8.5.3
Составление выписного эпикриза
M
R2.8.5.4
Регистрация факта освобождения койкоместа
M
R2.8.6
Формирование аналитических форм на
уровне врача. Данный процесс включает,
как минимум:
M
R2.8.6.1
процесс
Формирование отчетных форм:
1.
Отчет о проделанной работе
(количество пролеченных больных с
исходами)
2.
Отчет о количестве проведенных
операций (в том числе с осложнениями)
3.
Отчет о количестве проведенных
M
Раздел VI. Технические требования
279
манипуляций
4.
Отчет о деятельности коечного
фонда (работа койки, СДПБ, выполнение
койко дней, летальность)
5.
Отчет
об
использовании
диагностических исследований
6.
Отчет
процедурах
о
реабилитационных
R2.8.6.2
Формирование аналитических форм
M
R2.8.7
Ведение
первичной
учетной
документации
на
уровне
врача
стационара. Данный процесс включает,
как
минимум ведение следующих
учетных форм:
M
R2.8.7.1
003/у, 004-1/у, 005/у, 008/у, 011/у, 011-2/у,
011-3/у,027/у, 066/у, 066-4/у
M
R2.9
Модуль «9. Медсестра стационара»
R2.9.1
Ведение ЭМЗ пациента. Данный процесс
включает, как минимум:
M
R2.9.1.1
Полное описание процессов и требований
ведения ЭМЗ выполняется в соответствии
с национальным стандартом Электронной
M
Раздел VI. Технические требования
280
медицинской записи. (Утвержденный
Приказом и.о. Министра здравоохранения
№75 от 10.02.2014 г «Об утверждении
технической документации по вопросам
электронного здравоохранения»)
R2.9.1.2
Из тех данных, которые введены в ЭМЗ,
минимальный
обязательный
набор
данных передается в национальный ЭПЗ в
соответствии с национальным стандартом
Электронного
паспорта
здоровья
(Утвержденный Приказом и.о. Министра
здравоохранения №75 от 10.02.2014 г
«Об
утверждении
технической
документации по вопросам электронного
здравоохранения»)
M
R2.9.1.3
Уточнение демографических данных о
пациенте
M
R2.9.1.4
Функционал ведения плана лечения
M
R2.9.1.5
Регистрация нужных направлений (запись
на
прием)
в
лабораторные,
диагностические кабинеты и к другим
специалистам
в
соответствии
с
направлениями и назначениями врача
M
R2.9.1.6
Формирование отчетных форм:
1. Отчет по медикаментам и ИМН
M
Раздел VI. Технические требования
281
2.
Отчет о проведенных процедурах
3.
Отчет перевязочного кабинета
R2.9.2
Отметка о выполнении назначений и
лечения. Данный процесс включает, как
минимум:
M
R2.9.2.1
Отметка
о
пациентом
M
R2.9.2.2
Отметка о проведенных процедурах (для
исключительных
случаев,
когда
процедурный кабинет не имеет рабочих
мест для регистрации процедур)
M
R2.9.2.3
Отметка о перенесенных операциях (для
случаев, когда операционная не имеет
рабочих
мест
для
регистрации
проведенных операций)
M
R2.9.2.4
Ввод результатов лабораторных анализов
и диагностических тестов (в случае если у
соответствующих кабинетов нет рабочих
мест для регистрации результатов)
M
R2.9.3
Мониторинг состояния больного. Данный
процесс включает, как минимум:
M
R2.9.3.1
Отметка о проведенной оценке состояния
больного (температура, жалобы, и т.п)
M
лекарствах
принятых
Раздел VI. Технические требования
282
R2.9.3.2
Мониторинг реализации плана лечения
M
R2.9.3.3
Оповещение
ситуаций
M
R2.9.4
Ведение
первичной
учетной
документации на уровне медицинской
сестры. Данный процесс включает, как
минимум:
M
R2.9.4.1
Вывод на печать направлений и плана
лечения
M
в
случае
экстренных
Система должна быть способной вести
следующие учетные формы:
1.
004/у, 004-1/у, 007/у, 009/у, 029/у,
2.
Журнал забора крови на ВИЧ
3.
Журнал передачи реципиентов в
поликлинику
R2.9.4.2
4.
Журнал учета медикаментов
5.
Журнал
материала
учета
перевязочного
6.
Требование в аптеку
7.
Журнал учета и списания спирта
8.
Журнал
учета
наркотических
средств,
психотропных
веществ
и
M
Раздел VI. Технические требования
прекурсоров
30.03.2012г)
R2.9.5
283
(ПП
РК
№
396
от
Формирование аналитических форм на
уровне среднего медицинского персонала.
Данный процесс включает, как минимум:
M
Формирование отчетных форм:
1.
Отчет
об
использованных
медикаментах, в том числе наркотическим
веществам и спирту
2.
Отчет об использованных ИМН
3.
Отчет по определению группы
крови
R2.9.5.1
4.
Отчет
о
инфекционных больных
выявленных
М
5.
Отчет по переливанию крови и
кровезаменителей
6.
Отчет по забору крови и других
средств организма для исследования
7.
Отчет
материала
по
забору
биопсийного
8.
Отчет по направлениям на внешние
исследования
Раздел VI. Технические требования
284
R2.10
Модуль «10. Питание»
R2.10.1
Формирование
ежедневного
меню.
Данный процесс включает, как минимум:
M
R2.10.1.1
Формирование
меню-требования,
редактирование,
защита
от
редактирования после утверждения
M
R2.10.1.2
Формирование
меню-раскладок
с
указанием блюд, редактирование , защита
от редактирования после утверждения
M
R2.10.1.3
Просмотр списка блюд для каждого типа
диеты (Стола)
M
R2.10.1.4
Просмотр
списка
больных
отсортированных по диетам, палатам,
отделениям, и т.д.
M
R2.10.1.5
Просмотр
отзывов
больных
специалистов о качестве питания
M
R2.10.2
Калькулятор ежедневного, ежемесячного
расхода продуктов на меню. Данный
процесс включает, как минимум:
M
R2.10.2.1
Расчет необходимых продуктов на
конкретный день, с учетом списочного
состава больных по всей медицинской
организации
M
и
Раздел VI. Технические требования
285
R2.10.2.2
Корректировка количества необходимых
порций (с обязательным логированием
изменений) каждого типа диет
M
R2.10.2.3
Автоматический расчет количества
состава необходимых продуктов.
M
R2.10.2.4
Вывод на печать заказа на поставку
продуктов
M
R2.10.2.5
Просмотр всех вышеназванных данных
для предыдущих периодов (при этом
корректировка данных за предыдущие
периоды возможно только специальным
разрешением главного врача, которое
выдается на ограниченный срок)
M
R2.10.2.6
Возможность
просмотра
логирования
для
случаев
изменений количества порций
М
R2.10.3
Расчет пищевой ценности блюд в
рационе. Данный процесс включает, как
минимум:
M
R2.10.3.1
Расчет ценности блюд с учетом норм
отходов и потерь при различных видах
кулинарной обработки
M
R2.10.3.2
Автоматические подсказки по составу и
пищевой ценности для различных диет
M
и
журнала
ручных
Раздел VI. Технические требования
286
R2.10.3.3
Отчет о пищевой ценности по каждой
диете и приведением рекомендованных
стандартов по каждой диете
M
R2.10.4
Формирование справочников пищевых
продуктов, Данный процесс включает, как
минимум:
M
R2.10.4.1
Справочник
основных
продуктов и полуфабрикатов,
M
R2.10.4.2
Справочник карточек и состава блюд
M
R2.10.4.3
Справочник блюд диетического питания
(Столы 1-15)
M
R2.10.5
Управление диетой пациентов
M
R2.10.5.1
Просмотр рекомендаций о диетах от
специалистов и лечащих врачей для
каждого больного
M
R2.10.5.2
Назначение диеты (номер стола) больным
M
R2.10.5.3
Изменение диеты
M
R2.10.5.4
Просмотр отзывов пациентов и врачей о
качестве питания
M
R2.10.6
Формирование аналитических форм по
питанию.
M
пищевых
Раздел VI. Технические требования
287
R2.11
Модуль «11. Дневной стационар»
R2.11.1
Ведение ЭМЗ пациента . Данный процесс
включает, как минимум:
M
R2.11.1.1
Полное описание процессов и требований
ведения ЭМЗ выполняется в соответствии
с национальным стандартом Электронной
медицинской записи. (Утвержденный
Приказом и.о. Министра здравоохранения
№75 от 10.02.2014 г «Об утверждении
технической документации по вопросам
электронного здравоохранения»)
M
R2.11.1.2
Из тех данных, которые введены в ЭМЗ,
минимальный
обязательный
набор
данных передается в национальный ЭПЗ в
соответствии с национальным стандартом
Электронного
паспорта
здоровья
(Утвержденный Приказом и.о. Министра
здравоохранения №75 от 10.02.2014 г
«Об
утверждении
технической
документации по вопросам электронного
здравоохранения»)
M
R2.11.1.3
Формирование истории болезни
M
R2.11.1.4
Составление предварительного плана
лечения и дополнительных исследований
M
R2.11.1.5
Регистрация
M
визитов
и
обследования
Раздел VI. Технические требования
288
больного лечащим врачом
R2.11.2
Создание
направлений
на
консультативно-диагностические услуги.
Данный процесс включает, как минимум:
M
R2.11.2.1
Уточнение плана лечения, использование
плана во время лечения пациента,
изменение плана при необходимости.
M
R2.11.2.2
Формирование
направлений
на
лабораторные
анализы,
изучение
результатов и (при необходимости)
написание интерпретаций
M
R2.11.2.3
Формирование
направлений
на
диагностические исследования, изучение
результатов и написание интерпретаций
M
R2.11.2.4
Формирование
консультации
специалистам,
специалистов
M
R2.11.2.5
Мониторинг состояния направлений и
определение опозданий и отказов
M
R2.11.3
Регистрация врачебных назначений и их
выполнения. Данный процесс включает,
как минимум:
M
R2.11.3.1
Изучение аллергического анамнеза
M
направлений
на
к
другим
врачамизучение
заключений
Раздел VI. Технические требования
289
R2.11.3.2
Проверка совместимости лекарств
M
R2.11.3.3
Формирование назначений больным по
приему лекарств
M
R2.11.3.4
Назначение процедур
M
R2.11.3.5
Отметка о факте выполнения процедур
M
R2.11.3.6
Мониторинг
правильности
и
своевременности выполнения назначений
со стороны медицинской сестры и
вовлеченных участников лечения
M
R2.11.3.7
Регистрация фактов побочных действий и
осложнений лекарств и процедур
M
R2.11.4
Ведение
первичной
учетной
документации на уровне дневного
стационара
в
соответствии
с
действующими
нормативными
правовыми актами РК. Данный процесс
включает, как минимум:
M
R2.11.4.1
001-3/у, 001-4/у, 003-2/у, 004-1/у, 027/у,
029/у, 066-4/у
M
R2.11.5
Формирование аналитических форм на
уровне дневного стационара, а также
статистических таблиц в соответствии с
действующими
нормативными
M
Раздел VI. Технические требования
290
правовыми актами РК. Данный процесс
включает, как минимум:
Формирование отчетных форм:
1.
Отчет о проделанной работе
(количество пролеченных больных с
исходами)
2.
Отчет о количестве проведенных
операций (в том числе осложнения)
R2.11.5.1
3.
Отчет о количестве проведенных
процедур и манипуляций
M
4.
Счет –реестр за отчетный период с
указанием
стоимости
лечения
по
нозологическим формам
5.
Отчет
пребывания
о
средней
длительности
R2.11.6
Взаимодействие с ИС МЗСР РК. Данный
процесс включает как минимум:
M
R2.11.6.1
Обмен информацией
случаях
M
R2.11.6.2
Обмен
клинической
информацией
(диагнозы, результаты консультаций и
осмотров и т.д.)
M
R2.11.6.3
Обмен информацией о направлениях
M
о
пролеченных
Раздел VI. Технические требования
291
R2.11.6.4
Обмен информацией о рецептах
R2.12
Модуль «12. Заведующий отделением
стационара»
R2.12.1
Подтверждение
или
отклонение
направлений на отдельные виды услуг с
использованием ЭЦП.
M
R2.12.2
Ведение и согласование первичной
учетной
документации
на
уровне
заведующего отделением в соответствии с
действующими
нормативными
правовыми актами РК.
M
R2.12.2.1
Система
должна
быть
способной
регистрировать информацию следующих
первичных учетных форм:
035/у, 035-1/у, 035-2/у, 035-3/у, 094/у,
095/у
M
R2.12.3
Формирование аналитических форм на
уровне заведующего отделением, а также
статистических таблиц в соответствии с
действующими
нормативными
правовыми актами РК в форме и разрезах
аналогичных
таблицам
сотрудников
отделения. Перечень аналитических и
статистических форм должен быть
согласован с Заказчиком на этапе
проектирования Системы.
M
M
Раздел VI. Технические требования
292
R2.12.4
Согласование больничного листа, ведение
записей консилиума. Данный процесс
включает, как минимум:
M
R2.12.4.1
Согласование
длительных
нетрудоспособности
M
R2.12.4.2
Создание записей заседаний консилиума
M
R2.12.4.3
Формирование заключений консилиума
M
R2.12.4.4
Подпись заключений
помощью ЭЦП
листов
консилиума
с
M
Формирование отчетных форм:
1. Отчет о выданных листах временной
нетрудоспособности
2. Отчет о лицах прошедших через
консилиум
R2.12.4.5
3. Отчет о показателях работы коечного
фонда отделения
4. Отчет о пролеченных пациентах
5. Структура пролеченных случаев по
нозологическим группам и возрастам
6. Отчет по оказанным услугам по кодам
тарификатора
M
Раздел VI. Технические требования
293
R2.13
Модуль «13. Главный врач»
R2.13.1
Формирование аналитических форм на
уровне главного врача, а также
статистических таблиц в соответствии с
действующими
нормативными
правовыми
актами
РК.
Перечень
аналитических и статистических форм
должен быть согласован с Заказчиком на
этапе проектирования Системы.Данный
процесс включает, как минимум:
M
R2.13.1.1
Контроль
и
управление
ведения
первичной учетной документации в МО
M
R2.13.1.2
Аналитические формы и отчетные формы
доступные
всем
подразделениям
Организации
с
разделением
по
подразделениям.
M
R2.14
Модуль «14 Медицинская статистика
стационара»
R2.14.1
Ведение коечного фонда. Данный процесс
включает, как минимум:
M
R2.14.1.1
Ведение справочника коечного фонда в
разрезе подразделений, палат, коек
M
R2.14.1.2
Настройка использования коечного фонда
(разворачивание коек, сворачивание коек,
разворачивание
и
сворачивание
M
Раздел VI. Технические требования
294
временных
коек,
установление
максимального числа коек в палате,
ведение информации по профилям коек,
перепрофилированию коек, закрытию и
сокращению коек)
R2.14.1.3
Ввод дополнительной информации
койке, палате (мужская, женская)
R2.14.2
Формирование аналитических форм на
уровне кабинета медицинской статистики,
а также статистических таблиц в
соответствии
с
действующими
нормативными правовыми актами РК.
Формирование первичных форм
отчетных форм:
1.
Ежедневных :007/у, 007-1/у,
R2.14.2.1
о
M
M
и
2.
Ежемесячных: 016/у
3.
Форма 21
4.
9)
Форма 14 годовая (МКБ-10 и МКБ-
5.
Форма 32 годовая
6.
Форма 30 годовая
M
7.
перечень пролеченных
ВСМП с указанием операций;
случаев
8.
отчет о деятельности стационара;
9.
работа
отделений
в
разрезе
Раздел VI. Технические требования
295
профилей коек;
10.
состав больных, сроки и исходы;
11.
основные показатели деятельности
стационара;
12.
сведения о структуре всех видов
стационарной помощи;
13.
состав
диагнозов;
больных
по
группам
14.
состав пролеченных больных по
исходам;
15.
статистические данные о работе
ординаторов;
16.
хирургическая
отделениям;
17.
анализ
хирургической службы;
работа
по
деятельности
18.
свод по оперированным в разрезе
профилей коек;
19.
сведения
пребывании;
о
20.
операции
отделениям;
по
дооперационном
хирургическим
21.
состав больных по хирургическим
отделениям;
22.
анализ
деятельности
Раздел VI. Технические требования
296
реанимационного отделения;
23.
анализ летальности и совпадения
клинического и патологоанатомического
диагнозов;
24.
анализ
направительного
диагнозов;
и
совпадения
заключительного
25.
данные о пролеченных по районам
и областям;
26.
данные
о
направлениям «БГ»;
27.
пролеченных
данные по типам травм;
28.
данные
о
поступивших
алкогольном опьянении;
29.
по
в
список пролеченных больных;
30.
список
стационаре;
б-х
находящихся
31.
список
умерших
предоставления в РАГС;
в
для
32.
список умерших в стационаре в
разрезе районов;
33.
список
умерших
половозрастной структуре;
34.
информация
сельским жителям;
по
по
пролеченным
Раздел VI. Технические требования
35.
список
отделениям;
297
оперированных
36.
список оперированных
врачами отделений;
б-х
по
больных
37.
список больных по выбранным
диагнозам;
38.
список больных с осложнениями
после операции;
39.
список больных прошедших через
реанимацию;
40.
список больных переведенных в
др.стационар
41.
список пролеченных, оказавшихся
здоровыми;
42.
список
больных
льготную категорию;
имеющих
43.
список больных поступивших
повторно в течении месяца;
44.
половозрастной
пролеченных по профилям;
состав
45.
отчет по услугам диагностических
отделений;
46.
структура больных БСК в разрезе
нозологии, возрастов и исходов;
47.
отчет по пролеченным случаям в
Раздел VI. Технические требования
298
разрезе КЗГ.
R2.14.2.2
Мониторинг ведения первичной учетной
документации в Организации
M
R2.14.2.3
Конструктор
отчетных
форм
с
возможностью создания новых отчетных
форм и редактирования имеющихся
M
R2.15
Модуль «15. Процедуры и манипуляции»
R2.15.1
Ведение ЭМЗ пациента. Данный процесс
включает, как минимум:
M
R2.15.1.1
Полное описание процессов и требований
ведения ЭМЗ выполняется в соответствии
с национальным стандартом Электронной
медицинской записи. (Утвержденный
Приказом и.о. Министра здравоохранения
№75 от 10.02.2014 г «Об утверждении
технической документации по вопросам
электронного здравоохранения»)
M
R2.15.1.2
Из тех данных, которые введены в ЭМЗ,
минимальный
обязательный
набор
данных передается в национальный ЭПЗ в
соответствии с национальным стандартом
Электронного
паспорта
здоровья
(Утвержденный тем же приказом)
M
R2.15.1.3
Идентификация пациента
M
Раздел VI. Технические требования
299
R2.15.1.4
Отметка о
процедур
выполнении
назначенных
R2.15.1.5
Запись пациента на определенное время
при
необходимости
повторного
получения услуги
M
R2.15.2
Ведение
первичной
учетной
документации по оказанным процедурам
и манипуляциям в соответствии с
действующими
нормативными
правовыми актами РК . Данный процесс
включает, как минимум:
M
R2.15.2.1
029/у, 042/у,044/у, 046/у, 047/у, 058/у,
063/у, 064/у, 064-1/у, 064-2/у,
069/у, 150/у
M
R2.15.3
Формирование аналитических форм по
оказанным процедурам и манипуляциям,
а также статистических таблиц в
соответствии
с
действующими
нормативными правовыми актами РК.
Данный процесс включает, как минимум:
M
R2.15.3.1
Формирование отчетных форм:
Отчет о выполненных услугах (по
аппаратам, исполнителям, источникам
финансирования, видам услуг)
M
R2.16
Модуль «16. Администратор»
M
Раздел VI. Технические требования
300
R2.16.1
Управление базой данных. Данный
процесс включает, как минимум:
M
R2.16.1.1
Мониторинг
и
производительности БД
M
R2.16.1.2
Управление базой данных: настройка
хранилища, расширение базы данных
M
R2.16.1.3
Управление пользователями и паролями
БД
M
R2.16.1.4
Управление правами доступа
соответствии с Приложением 1
M
R2.16.1.5
Архивация данных за определенный
период времени о пациентах
M
R2.16.1.6
Восстановление данных из архивов на
отдельных серверах для поиска старых
данных.
M
R2.16.2
Создание
групп
пользователей
и
отдельных
пользователей
Системы.
Данный процесс включает, как минимум:
M
R2.16.2.1
Создание, удаление и редактирование
учетных записей пользователей;
M
R2.16.2.2
Создание, удаление и редактирование
ролей пользователей;
M
R2.16.2.3
Прикрепление
M
ролей
оптимизация
БД
в
конкретным
Раздел VI. Технические требования
301
пользователям
(один
и
пользователь может иметь
ролей)
тот
же
несколько
R2.16.2.4
Добавление, изменение и удаление прав
доступа
ролей
к
модулям,
первоначальные права должны быть
присвоены в соответствии с Приложением
1.
M
R2.16.2.5
Временный запрета доступа пользователя
в систему
M
R2.16.3
Управление типами аутентификации
(парольная, ЭЦП). Данный процесс
включает, как минимум:
M
R2.16.3.1
Создание первоначальных паролей
M
R2.16.3.2
Изменение
паролей
пользователей, которые
состоянии их менять
тех
не в
M
R2.16.3.3
Изменение политик управления паролями
M
R2.16.3.4
Использование внешних ключей
M
R2.16.3.5
Просмотр
попыток
невалидными ключами
R2.16.4
Ведение системных журналов. Данный
процесс включает, как минимум:
для
сами
доступа
с
M
M
Раздел VI. Технические требования
302
R2.16.4.1
Журнал создания, изменения и удаления
записей в базе данных
M
R2.16.4.2
Журнал истории входов пользователей
M
R2.16.4.3
Журнал получения отчетных форм
M
R2.16.4.4
Журнал просмотра данных
M
R2.16.4.5
Журнал действий по архивированию
M
R2.16.4.6
Журнал ошибок и аварийных остановок
программы
M
R2.16.4.7
Журнал синхронизации с внешними
(национальными)
справочниками,
классификаторами,
индексами
и
регистрами
M
R2.16.5
Настройка
шаблонов
медицинской
документации. Данный процесс включает,
как минимум:
M
R2.16.5.1
Создание новых шаблонов
M
R2.16.5.2
Изменение (создание новых
существующих шаблонов
R2.16.5.3
Прикрепление шаблонов к модулям и
пользователям и их открепление
версий)
M
M
Раздел VI. Технические требования
303
Использование
при
создании
и
редактировании шаблонов следующих
функций:
 изменение настроек шрифта (стиль,
размер, жирный, подчеркнутый,
курсив и т.д.)
 изменение цвета шрифта
 создание сложных шаблонов с
подразделами
 возможность
использования
любого справочника в системе для
заполнения поля в шаблоне
R2.16.5.4
 возможность использования любой
сущности в базе данных для
заполнения поля в шаблоне
 возможность использования любой
выборки из базы данных для
заполнения поля в шаблоне
 формирование правил заполнения
шаблона: только из списка, из
списка
с
возможностью
дополнения, в свободной форме, из
выборки и т.д.
 создание новых справочников,
используемых при заполнении
шаблона
M
Раздел VI. Технические требования
304
R2.16.6
Настройка пользовательского интерфейса.
Данный процесс включает, как минимум:
M
R2.16.6.1
Управление доступом к инструментам
интерфейса в зависимости от прав
доступа пользователей
M
R2.16.6.2
Возможность изменения стиля (например:
цветовой
гаммы,
размера
полей,
шрифтов)
M
R2.16.6.3
Возможность создания индивидуальных
шаблонов для каждого пользователя,
включая
присвоение
значений
по
умолчанию отдельным полям в шаблонах
данного пользователя.
M
R2.16.7
Настройка
доступа
пользователей.
Данный процесс включает, как минимум:
M
R2.16.7.1
Добавление, изменение и удаление прав
пользователей на действия (CRUD) в
Системе
M
R2.16.7.2
Управление (добавление, изменение и
удаление) доступом к данным в разрезе
организационной структуры предприятия:
в пределах структурного подразделения
закрепленного за пользователем, в
пределах всей медицинской организации
в соответствии с организационной
структурой предприятия
M
Раздел VI. Технические требования
305
R2.16.7.3
Закрепление за пользователем прав на
просмотр, создание, изменение, удаление
данных по конкретным структурным
подразделениям
M
R2.16.7.4
Добавление, изменение и удаление
доступа пользователей к отчетам
M
R2.16.7.5
Управление временем – графиком работы
работников,
в
течении
которого
пользователь имеет право доступа к
Системе
M
R2.16.7.6
Управление
доступом
к
данным
пациентов в соответствии с политикой
конфиденциальности
персональных
данных МЗСР РК.
M
R2.16.7.7
Установка признака конфиденциальности
для тех персональных данных, которые
должны храниться в базе данных в
зашифрованной форме
M
R2.16.7.8
Просмотр журналов (логов) с действиями
конкретных
пользователей
за
определенный период времени
M
R2.16.7.9
Архивация
и
очистка
журнала
логирования с данными о действиях
пользователей за определенный период в
соответствии с политиками МЗСР РК
M
Раздел VI. Технические требования
306
R2.16.7.10
Просмотра архивов логов
M
R2.16.8
Настройка
подключения
внешних
программ. Данный процесс включает, как
минимум:
M
R2.16.8.1
Разрешение доступа определенных IP
M
R2.16.8.2
Разрешение определенных программ и
сервисов
M
R2.16.8.3
Изменение паролей доступа внешних
программ
M
R2.16.9
Управление справочниками. Данный
процесс включает, как минимум:
M
R2.16.9.1
Изменение содержания (дополнение,
редактирование) локальных справочников
системы
M
R2.16.9.2
Мониторинг процесса синхронизации
внешних (национальных) справочников,
индексов и регистров
M
R2.16.9.3
Мониторинг
правильности
(или
возможных проблем) обмена данными с
внешними
источниками
данных
(национальный
ЭПЗ,
национальное
аналитическое хранилище)
M
R2.16.9.4
Изменение
M
графика
синхронизации
с
Раздел VI. Технические требования
307
внешними информационными ресурсами
R2.16.10
Создание, редактирование отчетных форм
при помощи мастера отчетных форм
позволяющий создавать и редактировать
отчетные формы с использованием полей
из базы данных Системы. Данный
процесс включает, как минимум:
M
R2.16.10.1
Создание отчетных форм
M
R2.16.10.2
Редактирование отчетных форм
M
R2.16.10.3
Удаление отчетных форм
M
R2.16.10.4
Настройка
прав
пользователей
использование отчетных форм
R2.17
Модуль
«17.
Лабораторная
информационная система»
R2.17.1
Регистрация поступившего материала с
возможностью
отбраковки.
Данный
процесс включает, как минимум:
M
R2.17.1.1
Ведение персонифицированного учета
проводимых исследований, поддержка
карточки пациента в базе данных ЛИС
M
R2.17.1.2
Создание новой карточки пациента с
присвоением
уникального
M
на
M
Раздел VI. Технические требования
308
идентификационного
номера
после:
автоматически получения данных из
других модулей о поступлении нового
пациента, автоматически после получения
(считывания) направления, занесения
данных пациента с направления вручную
R2.17.1.3
Считывание бланков установленного
образца
с
помощью:
оптическое
распознавание
символов
(OCR),
оптическое распознавание отметок (OMR)
M
R2.17.1.4
Регистрация поступившего материала с
привязкой к пациенту
M
R2.17.1.5
Присвоение
идентификационного
материалу
M
R2.17.1.6
Возможность отбраковки поступившего
материала с указанием причины (из
справочника и/или вручную)
уникального
номера каждому
M
Формирование отчетных форм:
1. Отчет о количестве поступившего
материала
R2.17.1.7
2. Отчет о количестве материала
отбракованного по различным
причинам
M
Раздел VI. Технические требования
309
R2.17.2
Штрих-кодирование материала (создание
штрих-кодов, идентификация по штрихкоду). Данный процесс включает, как
минимум:
M
R2.17.2.1
Присвоение штрихкода материалу
M
R2.17.2.2
Присвоение
образцам
M
R2.17.2.3
Считывание штрихкода с помощью
стационарных и переносных сканеров
штрихкодов
M
R2.17.2.4
Поддержка формирования данных на
основе большинства из следующих
штрихкодов Code 39, Code 93, Code 128,
Codebar, European Article Number (EAN),
ITF-14, MSI Barcode, Universal Product
Code, а также двумерных кодов PDF417,
Aztec Code, Data Matrix, Maxi Code, QRкод, Microsoft Tag
M
R2.17.3
Формирование рабочих листов для
лабораторных
анализаторов
и
исполнителей. Данный процесс включает,
как минимум:
M
R2.17.3.1
Формирование заказов на исследования
на основе поступивших из МИС
направлений
M
штрихкода
отдельным
Раздел VI. Технические требования
310
R2.17.3.2
Формирование заказов на исследования
на основе ручного ввода данных
M
R2.17.3.3
Включение в один заказ нескольких
материалов
M
R2.17.3.4
Использования при заказе профилей услуг
(множественные исследования)
M
R2.17.3.5
Заказ комплексных услуг (одна услуга с
несколькими материалами)
M
R2.17.3.6
Автоматическое
распределение
исследований по рабочим листам на
основе конфигурируемых критериев (вид
исследования,
время
исследования,
исполнитель)
M
R2.17.3.7
Ручное распределение исследований по
рабочим местам
M
R2.17.3.8
Перераспределение
исследований
одних рабочих листов в другие
M
R2.17.3.9
Изменение исполнителя в рабочем листе
M
R2.17.3.10
Вывод на печать рабочих листов для
организации
выполнения
ручных
исследований
M
R2.17.4
Взаимодействие
с
лабораторным
оборудованием (экспорт направлений на
M
из
Раздел VI. Технические требования
311
исследование,
импорт
результатов
исследований).
Данный
процесс
включает, как минимум:
R2.17.4.1
Подключение анализаторов, станций
пробоподготовки и иных аппаратов,
имеющих возможность подключения к
ЛИС
M
R2.17.4.2
Отправка заданий на анализаторы
M
R2.17.4.3
Получение результатов от анализаторов и
распределение их по карточкам пациентов
M
R2.17.4.4
Получение
результатов
внутрилабораторного контроля качества
от анализаторов
M
R2.17.4.5
Просмотр, редактирование, удаление,
обработка, утверждение результатов
M
R2.17.5
Ручной ввод результатов лабораторных
исследований. Данный процесс включает,
как минимум:
M
R2.17.5.1
Настройка шаблонов результатов
M
R2.17.5.2
Ручной
ввод
исследований
M
R2.17.5.3
Настраиваемый алгоритм расчета готовых
результатов на основе вводимых данных
готовых
результатов
M
Раздел VI. Технические требования
312
Обработка
результатов
бактериологических исследований:
 Система обработки должна быть
открытой
и
позволять
пользователю
в
рамках
вложенной в нее классификации
самостоятельно дополнять такие
разделы,
как:
антибиотики,
диагнозы,
биоматериалы,
микроорганизмы,
R2.17.5.4

Перечень диагнозов в системе
должен быть составлен МКБ-10,
список
антибактериальных
препаратов
должен
быть
составлен по международной
классификации,
таксонов
—
изданию
перечень
по
последнему
«Определитель
бактерий Берджи»,

Антибиотикограмма
выстраиваться
на
должна
основании
M
Раздел VI. Технические требования
313
данных,
введенных
пользователем
любым
из
и
полученных
методов
диффузионным,
(дискометодом
предельных концентраций или
при определении минимальной
подавляющей концентрации),

Система
обработки
на
основании заложенных в нее
данных
о
устойчивости
природной
отдельных
микроорганизмов или их групп,
о распространении среди них
приобретенной резистентности,
а также сведений о клинической
эффективности
антибактериальных препаратов,
должна
результаты
интерпретировать
исследования
антибиотикочувствительности,
Раздел VI. Технические требования
314
полученные in vitro, в степень
чувствительности (S, I, R) и, при
необходимости,
их
корректировать или выдавать
сообщение об ошибке,
Формирование отчетных форм:
1. Отчет
о
выполненных
исследованиях
2. Отчет
об
антибиотикорезистентности
выделенных культур (в целом по
Организации и по подразделениям)
R2.17.5.5
3. Отчет по видам лабораторных
исследований
(клинические,
биохимические, гематологические,
иммунологические,
бактериалогические и др.)
4. 261/у
5. 262/у
6. Форма №1 АПО (Отчет
дорогостоящим
услугам
сравнении с планом)
по
в
M
Раздел VI. Технические требования
315
R2.17.6
Подтверждение
действительности
результатов лабораторных исследований
уполномоченным
сотрудником
лаборатории. Данный процесс включает,
как минимум:
M
R2.17.6.1
Просмотр
результатов
исследований
M
R2.17.6.2
Сравнение с референсными значениями с
визуальной индикацией отклонений
M
R2.17.6.3
Построение контрольных карт для оценки
качества результатов
M
R2.17.7
Контроль
качества
лабораторных
исследований
(внутрилабораторный,
межлабораторный, внешний). Данный
процесс включает, как минимум:
M
R2.17.7.1
Регистрация ежедневных результатов
исследования контрольных материалов
M
R2.17.7.2
Регистрация
эталонных
контрольных материалов
M
R2.17.7.3
Оценка
полученных
значений
в
соответствии с эталонными значениями
M
R2.17.7.4
Формирование протоколов исследования
контрольных
препаратов
для
межлабораторного и внешнего сличения
M
выполнения
значений
Раздел VI. Технические требования
316
R2.17.8
Возможность
вывода
на
печать
результатов на основании утвержденной
действующими
нормативными
правовыми актами РК первичной учетной
документации. Данный процесс включает,
как минимум:
M
R2.17.8.1
Создание и редактирование шаблонов
бланков и журналов
M
R2.17.8.2
Вывод
результатов
на
печать
в
соответствии
с
утвержденными
(R2.18.10.1)
и
пользовательскими
формами
M
R2.17.8.3
Вывод журналов на печать в соответствии
с утвержденными формами (R2.18.10.1)
M
R2.17.9
Введение референсных значений по
лаборатории как для всех пациентов, так и
по половозрастным группам. Данный
процесс включает, как минимум:
M
R2.17.9.1
Введение референсных
половозрастным группам
M
R2.17.9.2
Формирование референсных значений
отдельных
показателей
на
основе
статистической обработки результатов
лаборатории
M
R2.17.9.3
Формирование отчетных форм:
M
значений
по
Раздел VI. Технические требования
317
1.
Референсные
значения
лаборатории (по группам пациентов и по
видам лабораторных исследований)
R2.17.10
Ведение
первичной
учетной
документации на уровне лаборатории в
соответствии
с
действующими
нормативными правовыми актами РК.
Данный процесс включает, как минимум
ведение следующих учетных форм:
M
R2.17.10.1
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/у, 257/у,
259/у, 261/у, 262/у,280/у,
M
R2.17.11
Формирование аналитических форм на
уровне
лаборатории,
а
также
статистических таблиц в соответствии с
действующими
нормативными
правовыми актами РК. Данный процесс
включает, как минимум:
M
Раздел VI. Технические требования
318
R2.17.11.1
Формирование отчета лаборатории по
выполненным исследованиям (Форма 30)
M
R2.17.12
Возможность интеграции Системы с
самостоятельными
Лабораторными
информационными системами. Данный
процесс
предполагает
соответствие
необходимым профилям IHE
M
R2.17.13
Передача информации о выполненных
исследованиях в ЭМЗ и ЭПЗ. Данный
процесс включает, как минимум:
M
R2.17.13.1
Передача информации о выполненных
лабораторных исследованиях и их
результатах в ЭПЗ в соответствии со
Стандартными требованиями к ЭПЗ,
утвержденными приказом и.о. Министра
здравоохранения РК №75 от 10.02.2014 г
«Об
утверждении
технической
документации по вопросам электронного
здравоохранения»
M
R2.17.13.2
Передача информации о выполненных
лабораторных исследованиях и их
результатах в ЭМЗ в соответствии со
Стандартными требованиями к ЭМЗ,
утвержденными приказом и.о. Министра
здравоохранения РК №75 от 10.02.2014 г
«Об
утверждении
технической
документации по вопросам электронного
здравоохранения»
M
Раздел VI. Технические требования
319
R2.18
Модуль «18. PACS» (Picture Archiving
and Communication System)
R2.18.1
Обмен данными с медоборудованием.
Данный процесс включает, как минимум:
M
R2.18.1.1
Импорт данных в
стандартом DICOM
M
R2.18.1.2
Импорт напрямую с видеовыходов (при
наличии необходимого оборудования)
M
R2.18.2
Взаимодействие с другими модулями и
системами на основе правил IHE
профилей
M
R2.18.3
Импорт/экспорт изображений. Данный
процесс включает, как минимум:
M
R2.18.3.1
Поддержать
JPEG
M
R2.18.3.2
Поддержка DICOM Modality Worklist
M
R2.18.3.3
Возможность сохранения изображений
как приложения к документам CDA
M
R2.18.3.4
Поддержка сканирования бумажных и
пленочных изображений для составления
электронного архива
M
R2.18.3.5
Аудит случаев импорта-экспорта
M
форматы
соответствии
DICOM.
со
BMP,
Раздел VI. Технические требования
320
R2.18.4
Работа с изображениями. Данный процесс
включает, как минимум:
M
R2.18.4.1
Просмотр
единичных
изображений,
M
R2.18.4.2
Вызов
из
архива
и
появление
изображения на экран не позже чем 3-5
сек после запроса
M
R2.18.4.3
Выделение
областей
изображении,
M
R2.18.4.4
Наложение комментариев
M
R2.18.4.5
Обработка изображений для улучшения
качества
M
R2.18.4.6
Быстрый поиск данных о пациенте и
изображений пациента
M
R2.18.4.7
Связь
метаданных
изображениями
M
R2.18.4.8
Связь изображений с интерпретацией и
диагностическими результатами
M
R2.18.4.9
Аудит
просмотра
изображений
M
R2.18.5
Ведение архива изображений. Данный
процесс включает, как минимум:
и
серий
интереса
пациента
и
на
с
обработки
M
Раздел VI. Технические требования
321
R2.18.5.1
Возможность
изображений
долгосрочного
R2.18.5.2
Хранение идентификационных данных
пациента
во
избежание
ошибок
присвоения
изображений
другими
пациентами.
M
R2.18.5.3
Возможность интеграции
системами организации
M
R2.18.5.4
Возможность передачи изображений (при
необходимости) в других системах и в
национальный репозиторий ЭПЗ
R2.19
Модуль
«19.
исследования»
R2.19.1
Просмотр записанных по графику
пациентов. Данный процесс включает, как
минимум:
M
R2.19.1.1
Просмотр графика
пациентами
M
R2.19.1.2
Просмотр направлений, созданных на
диагностические исследования
M
R2.19.1.3
Получение списка пациентов, записанных
на исследования
M
R2.19.1.4
Отмена
или
исследования с
M
с
хранения
другими
M
M
Диагностические
с
записанными
перенос
указанием
времени
причины
Раздел VI. Технические требования
322
переноса
и
заинтересованных сторон
уведомлением
Формирование отчетных форм:
1.
Отчет о записанных на прием
R2.19.1.5
2.
Отчет об отмененных посещениях
3.
Отчет о выполненных услугах
4.
Отчет о дозах облучения персонала
и пациента
M
5.
Отчет по очередности и сроком
ожидания диагностических исследований
6.
Формирование списка пациентов в
разрезе оказанных услуг по кодам
тарификатора
R2.19.2
Ввод результатов исследований на основе
шаблонов. Данный процесс включает, как
минимум:
M
R2.19.2.1
Создание и редактирование шаблонов
консультаций, заключений, результатов
исследований
M
R2.19.2.2
Заполнение результатов исследований на
основе шаблонов
M
R2.19.2.3
Поиск предыдущих заключений пациента
M
R2.19.2.4
Вывод
M
результатов
исследований
на
Раздел VI. Технические требования
323
печать в утвержденной форме
R2.19.2.5
Формирование отчетных форм:
1.
Отчет о выполненных услугах (в
разрезе
аппаратов,
исполнителей,
источников
финансирования,
видов
исследований,
направляющих
подразделений)
M
2.
Отчет о дозах облучения персонала
и пациента
3.
Список пациентов в разрезе
оказанных услуг по кодам тарификатора
R2.19.3
Ведение
первичной
учетной
документации
по
диагностическим
исследованиям
в
соответствии
с
действующими
нормативными
правовыми актами РК. Данный процесс
включает,
как
минимум
ведение
следующих учетных форм:
M
R2.19.3.1
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/у, 2473/1/у ,247-3/2/у, 247-4/у, 247-5/у, 247-6/у,
247-7/у,
M
R2.19.3.2
Протокол измерения индивидуальных доз
(приказ МЗ РК №902 от 20.12.11 г)
M
Раздел VI. Технические требования
324
R2.19.4
Формирование аналитических форм по
диагностическим исследованиям, а также
статистических таблиц в соответствии с
действующими
нормативными
правовыми
актами
РК.
Перечень
аналитических и статистических форм
должен быть согласован с Заказчиком на
этапе проектирования Системы.
M
R2.19.5
Передача информации о выполненных
исследованиях в ЭМЗ и ЭПЗ. Данный
процесс включает, как минимум:
M
R2.19.5.1
Передача информации о выполненных
диагностических исследованиях и их
результатах в ЭПЗ в соответствии со
Стандартными требованиями к ЭПЗ,
утвержденными приказом и.о. Министра
здравоохранения РК №75 от 10.02.2014 г
«Об
утверждении
технической
документации по вопросам электронного
здравоохранения»
M
R2.19.5.2
Передача информации о выполненных
диагностических исследованиях и их
результатах в ЭМЗ в соответствии со
Стандартными требованиями к ЭМЗ,
утвержденными приказом и.о. Министра
здравоохранения РК №75 от 10.02.2014 г
«Об
утверждении
технической
документации по вопросам электронного
здравоохранения»
M
Раздел VI. Технические требования
325
R2.19.5.3
Осуществление обмена в соответствии с
IHE профилями
R2.20
Модуль «20. Аптека»
R2.20.1
Ведение учета медикаментов на разных
уровнях: поста, кабинета, отделения,
аптечного
склада
(одного
или
нескольких), медицинской организации.
Данный процесс включает, как минимум:
M
R2.20.1.1
Ведение полноценного складского учета
на одном или нескольких центральных
складах
M
R2.20.1.2
Ведение полноценного складского учета
для каждого материально ответственного
лица
M
R2.20.1.3
Просмотр складских остатков по каждому
складу (по группе медикаментов, по
фармакологическим
и
фармакотоксическим
группам,
по
медикаменту,
по
поставщику,
по
отделению)
M
R2.20.1.4
Установление количества неснижаемых
остатков по каждому медикаменту
M
R2.20.1.5
Установление
базовых
перечней
медикаментов для каждого отделения
M
M
Раздел VI. Технические требования
326
R2.20.1.6
Контроль за исполнением неснижаемых
остатков
M
R2.20.2
Автоматическое списание лекарственных
средств при выполнении назначения.
M
R2.20.3
Возможность
отслеживания
годности ЛС и ИМН.
M
R2.20.4
Возможность формирования перечня
лекарственных
средств
(изделия
медицинского назначения) необходимых
для закупа в организациях.
M
R2.20.5
Формирование требований в аптеку на
получение
лекарственных
средств
(автоматические срочные требования при
наличии в листе назначений и отсутствии
в отделении, при снижении запаса ниже
установленного критического минимума).
Данный процесс включает, как минимум:
M
R2.20.6
Получение
сведений
о
наличии
лекарственного препарата в отделениях
МО. Данный процесс включает, как
минимум:
M
R2.20.7
Ведение
формуляра
лекарственных
средств
медицинской
организации.
Данный процесс включает, как минимум:
M
R2.20.7.1
Создание формуляра Организации
M
сроков
Раздел VI. Технические требования
327
R2.20.7.2
Внесение лекарственных препаратов в
формуляр Организации с указанием
документа, являющегося основанием
M
R2.20.7.3
Исключение лекарственных препаратов
из формуляра Организации с указанием
документа, являющегося основанием
M
R2.20.8
Регистрация побочного действия (ПД)
лекарственного средства. Данный процесс
включает, как минимум:
M
R2.20.8.1
Формирование карты-сообщения (форма
№192-1/у
приказ
и.о.Министра
здравоохранения Республики Казахстан
от 03 ноября 2009 года №647)
M
R2.20.8.2
Регистрация
случая
в
Журнале
регистрации
выявленных
случаев
побочных действий (форма №192-3/у
приказ и.о.Министра здравоохранения
Республики Казахстан от 03 ноября 2009
года №647)
M
R2.20.8.3
Формирование отчетных форм:
1.
Формирование
статистического
отчета о случаях побочных действий,
серьезных
побочных
действий
и
отсутствия эффективности (ПД, СПД и
ОЭ) лекарственных средств (ЛС) в
медицинских
и
фармацевтических
M
Раздел VI. Технические требования
328
организациях (форма №192-4/у приказ
и.о.Министра
здравоохранения
Республики Казахстан от 03 ноября 2009
года №647)
R2.20.9
Мониторинг назначений лекарственных
средств. Данный процесс включает, как
минимум:
M
R2.20.9.1
Просмотр назначений лекарственных
препаратов
в
подразделениях
Организации
M
R2.20.9.2
Сортировка назначений по дате, врачу,
диагнозу, и иным параметрам
M
R2.20.9.3
Просмотр связки диагноз-лекарственный
препарат
M
R2.20.9.4
Ввод
данных
о
препаратах,
рекомендуемых клинических руководств
и протоколов диагностики и лечения
M
R2.20.9.5
Ввод
данных
лекарственных
предотвращения
назначения
M
R2.20.9.6
Сравнение назначений с перечнем в
соответствии
с
клиническими
протоколами и руководствами
о
взаимодействии
средств,
для
их
совместного
M
Раздел VI. Технические требования
329
R2.20.9.7
Направление сообщений с рекомендацией
о замене лекарственных препаратов
M
R2.20.10
Установка максимальных дозировок для
контроля назначений. Данный процесс
включает, как минимум:
M
R2.20.10.1
Установка максимальных дозировок в
различных видах (на кг МТ, разовая,
суточная и т.д.)
M
R2.20.10.2
Установка максимальных дозировок для
различных
возрастнополовых
групп
пациентов
M
R2.20.10.3
Установка максимальных дозировок для
отдельных нозологий
M
R2.20.10.4
Просмотр
заявок
на
превышение
установленных максимальных дозировок
M
R2.20.10.5
Разрешение
на
превышение
установленных максимальных дозировок
с указанием причин
M
R2.20.11
Регистрация
и
оформление
приходных/расходных
документов
отделений и аптеки в соответствии с
нормативно-правовыми акта. Данный
процесс включает, как минимум:
M
R2.20.11.1
Создание, редактирование и регистрация
приходно-расходных фактур
M
Раздел VI. Технические требования
330
R2.20.11.2
Создание, редактирование и регистрация
отложенных приходно-расходных фактур
M
R2.20.11.3
Формирование
требований
на
медикаменты от старших медицинских
сестер отделений, в том числе на основе
зарегистрированных назначений
M
R2.20.11.4
Оформление накладной на медикаменты и
расходные материалы по требованиям на
поставку медикаментов от старших сестер
отделений
M
R2.20.11.5
Создание, редактирование и регистрация
накладной возврата медикаментов на
склад из отделений
M
R2.20.11.6
Создание, редактирование и регистрация
заказов поставщикам
M
R2.20.11.7
Создание, редактирование и регистрация
отложенных приходно-расходных фактур
по выполнению заказов на медикаменты
M
R2.20.12
Ведение
первичной
учетной
документации на уровне аптеки в
соответствии
с
действующими
нормативными правовыми актами РК.
M
R2.20.13
Формирование аналитических форм на
уровне аптеки, а также статистических
таблиц в соответствии с действующими
M
Раздел VI. Технические требования
331
нормативными правовыми актами РК.
Перечень
аналитических
и
статистических форм должен быть
согласован с Заказчиком на этапе
проектирования Системы.
R2.20.14
Формирование заявки на необходимые
лекарственные средства на уровне
отделения, поликлиники, стационара по
территории обслуживания
M
R2.20.15
Формирование отчета по планированию
расходов на лекарственные средства с
учетом льготных препаратов.
M
R2.20.16
Взаимодействие с другими модулями при
необходимости обмена информацией о
лекарственных препаратах
M
R2.21
Модуль «21. Кадры»
R2.21.1
Связь с национальными индексами.
Данный процесс включает, как минимум
связь со следующими индексами:
M
R2.21.1.1
«Регистр медицинских работников »
M
R2.21.1.2
«Регистр организаций здравоохранения»
M
R2.21.1.3
«Адресный регистр»
M
Раздел VI. Технические требования
332
R2.21.1.4
«Специальностей здравоохранения»
M
R2.21.1.5
«Список должностей (функций)»
M
R2.21.1.6
«Список медицинских услуг»
M
R2.21.2
Ведение организационной структуры МО.
Данный процесс включает, как минимум:
M
R2.21.2.1
Создание,
редактирование,
удаление
подразделений медицинских организаций
(кабинетов, подразделений, отделений,
департаментов и др.- в соответствии с
организационной
структурой
организаций)
M
R2.21.2.2
Ведение
организации
M
R2.21.2.3
Формирование
должностей
R2.21.2.4
Связь между кабинетами/офисами и
специалистами,
предоставляющими
услуги
M
R2.21.2.5
Связь
подразделений
предоставляемых услуг
M
R2.21.3
Ведение
учетной
карточки
врача
(работника здравоохранения). Данный
процесс включает, как минимум:
штатного
расписания
ведомостей
со
замены
списком
M
M
Раздел VI. Технические требования
333
R2.21.3.1
Прием сотрудника на работу
M
R2.21.3.2
Ввод
следющией
минимальной
информации о сотруднике:
История трудовых отношений, эпизоды
трудовой деятельности, личные сведения
(номер
удостоверения,
номер
пенсионного договора, состоит ли в браке,
состав семьи, место жительства, место
прописки,
контактная
информация,
количество детей, отношение к воинской
службе,
номер
индивидуального
трудового договора), информация о
участии в боевых действиях, ликвидации
аварий, стихийных бедствий, поощрения,
взыскания, знание языков, информация о
социальных наградах, об образовании,
сертификатах специалиста, повышениях
квалификации, ученых званиях, ученых
степенях.
M
R2.21.3.3
Регистрация
материальной
ответственности сотрудников
M
R2.21.3.4
Прием на дополнительную должность
M
R2.21.3.5
Перевод на
Организации
R2.21.3.6
Увольнение сотрудника
другую
должность
в
M
M
Раздел VI. Технические требования
334
R2.21.3.7
Ведение
графиков
квалификации
повышения
R2.21.3.8
Просмотр и печать списка работников
отобранных по определенным критериям
M
R2.21.4
Ведение режима работы работников.
Данный процесс включает, как минимум:
M
R2.21.4.1
Планирование и учет
отпусков работников
M
R2.21.4.2
Составление режима работы с учетом
выходных и отпусков
M
R2.21.4.3
Учет
замен
и
пропусков работы
M
R2.21.4.4
Печать режима работы и графиков
отпусков по отдельным работникам, по
кабинетам
(точек
представления
медицинских услуг), по управлениям/
отделениям, по организации
M
R2.21.4.5
Печать
ведомостей
фактически
отработанного времени, отпусков по
отдельным работникам, по кабинетам
(точек
представления
медицинских
услуг), по управлениям/ отделениям, по
организации
M
R2.21.5
Ведение справочника услуг. Данный
процесс включает, как минимум:
M
выходных
и
незапланированных
M
Раздел VI. Технические требования
335
R2.21.5.1
Связь с национальным индексом услуг
R2.21.5.2
Добавление и удаление услуг
справочника услуг организации
R2.21.5.3
Привязка предоставленных
подразделениям организации
R2.21.5.4
Просмотр/ печать списка услуг каждого
подразделения и организации в целом
M
R2.21.6
Связь с информационной системой
бухгалтерского учета (как минимум с
бухгалтерскими продуктами «1С» версии
8). Данный процесс включает, как
минимум:
M
R2.21.6.1
Передача данных о новых сотрудниках
M
R2.21.6.2
Передача
данных
должностях
M
R2.21.6.3
Передача данных об отработанных днях
(часах) работников
M
R2.21.6.4
Обмен информацией об отпусках
M
R3
Требования к конфигурации системы
R3.1
Конфигурация
к
медицинских организаций
об
услуг
M
из
к
измененных
потребностям
M
M
Раздел VI. Технические требования
336
R3.1.1
Поставляемая система должна содержать
в свой состав обязательные модули в
соответствии с Таблицей 1 в зависимости
от типа медицинской организации:
Стационар, Поликлиника, Смешанного
типа (Стационар + Поликлиника) (см.
также R1.17-R1.18)
М
R3.1.2
Система должна обеспечить возможность
управления доступом к функционалу на
основе ролей. Система должна позволять
добавлять/удалять/редактировать роли и
присвоить/отменить право доступа к
функционалу системы.
М
R3.1.3
Система
должна
иметь
предустановленные роли в соответствии с
Таблицей 3 с возможностью дальнейшего
изменения (добавления новых ролей,
редактирования или удаления).
М
R3.1.4
Права доступа к различным модулям и
функциям
системы
должны
быть
предустановлены в соответствии с
Таблицей 4 с возможностью изменения
прав доступа (добавления, удаления)
М
R3.1.5
Права доступа должны быть как минимум
конфигурируемыми
по
следующим
аспектам: все права, создание, изменение,
удаление, просмотр.
М
Раздел VI. Технические требования
337
R4.1
Поиск пациента по ФИО или ИИН а
также связанных с пациентом данных
(результаты обследования, результаты
лабораторных исследований и другое) не
должен занимать более 5 секунд для 80%
случаев
M
R4.2
Поставщик в течение гарантийного срока
должен
обеспечивать
следующие
параметры функционирования системы:
М
R4.2.1
Суммарное время простоя Системы по
причинам,
связанным
с
ее
работоспособностью
не
должно
превышать 24 часов в год.
М
R4.2.2
Время однократного простоя Системы по
причинам,
связанным
с
ее
работоспособностью
не
должно
превышать 2 часов.
М
R5
Требования
безопасности
R5.1.
Требования безопасности определяются
действующим
законодательством
Республики Казахстан. Система должна
соответствовать
требованиям
информационной
безопасности
по
обеспечению порогового доступа, защите
от несанкционированного доступа и др.
к
информационной
M
Раздел VI. Технические требования
338
R5.2.
В системе должны быть предусмотрены
средства
защиты
информации
от
несанкционированного доступа, а именно:
M
R5.3.
Идентификация пользователя на основе
проверки имени (логина) пользователя и
пароля
M
R5.4.
Возможность
идентификации
пользователя, основанной на цифровых
сертификатах инфраструктуры открытых
ключей
M
R5.5.
Авторизация пользователя для доступа к
информационно-вычислительным
ресурсам Системы, требующим наличия
соответствующих разрешений
M
R5.6.
Персонифицированное определение прав
пользователей на ввод, корректировку,
просмотр данных
M
R5.7.
Персонифицированное определение прав
пользователей на доступ к ресурсам
Системы
M
R5.8.
Разграничение
прав
пользователей
системы по ролям, группам и уровню
доступа с учётом иерархии объектов и
принадлежности
к
организационной
структуре.
M
Раздел VI. Технические требования
339
R5.9.
Протоколирование работы пользователей
с
критическими
функциями
и
приложениями Системы
M
R5.10.
Защиту
системных
файлов
от
изменения/повреждения
неавторизованными пользователями и
программными процессами
M
R5.11.
Должен вестись контрольный журнал
всех
обновлений
в
библиотеках
системных программ
M
R5.12.
В системе должны быть реализованы не
менее
чем
следующие
средства
резервного копирования:
- автоматическое резервное копирование с
возможностью планирования
- удаленное управление созданием
резервной копии
- полное и частичное резервное
копирование
M
R5.13.
Система
должна
целостность данных.
M
R5.14.
Система
должна
предоставлять
инструменты
для
шифрования
конфиденциальных данных во время
хранения и в процессе передачи в другие
системы.
обеспечивать
M
Раздел VI. Технические требования
340
R5.15.
Электронно-цифровая подпись (далее регистрационное
свидетельство
пользователя
Национальным
Удостоверяющим Центром Республики
Казахстан, ЭЦП) должна быть выпущена
НУЦ РК. Система должна обеспечить
инструменты для цифровой подписи
документов (объектов) или частей
документов, когда/если это необходимо, и
инструменты
для
аутентификации
подписей. Эта возможность должна быть
реализована в сервисах Системы (если это
необходимо).
Для
обеспечения
подтвреждения полдинности ЭЦП и
действительности открытого ключа ЭЦП,
Система должна осушествлять проверки
подлинности ЭЦП посредством сервисов
НУЦ РК. (http://pki.gov.kz/index.php/ru/).
M
R5.16.
Система
должна
соответствовать
принципу «единой точки доступа» архитектура
информационной
инфраструктуры позволяющая иметь
общую точку доступа (технология Single
Sign On) ко всем ее компонентам и
ресурсам, что позволяет ввести логин и
пароль один раз и получить доступ ко
всем
компонентам
Системы
без
повторного ввода пароля.
M
R5.17.
Система
M
должна
обеспечивать
Раздел VI. Технические требования
341
авторизацию пользователей в Системе,
разграничение
прав
пользователей
системы по ролям, группам и уровню
доступа с учётом иерархии объектов и
принадлежности
к
организационной
структуре.
R5.18.
В
соответствии
с
нормативнотехнической
документацией
по
информационной
безопасности,
утвержденной МЗСР РК должно быть
реализовано следующее:
− длина пароля должна быть
не менее 8 символов, должны
присутствовать буквы и цифры в
верхнем и нижнем регистрах;
− функция
принудительной
смены пароля;
− функция
запрета
использования в качестве пароля
«пустой» пароль;
− самостоятельная
смена
пароля пользователем;
− при
введении
неправильного пароля более трех
раз должен быть реализован метод
CAPTCHA;
− журнал
логирования
действий
всех
пользователей,
предназначенный для просмотра
истории
изменений
основных
M
Раздел VI. Технические требования
342
событий Системы;
− функционал
прерывания
сессии при неактивности через N
количество времени.
R6
Требования к атрибутам качества системы
R6.1.
Система должна поддерживать ввод,
получение
и
передачу
данных
необходимых для работы ИС МЗСР РК
используемых Организацией и исключать
необходимость повторного ввода данных.
M
R6.2.
Система должна обеспечивать сохранение
всей накопленной на момент отказа или
выхода из строя информации при отказе
любого компонента Системы независимо
от его назначения, с последующим
восстановлением
после
проведения
ремонтных и восстановительных работ
M
R6.3.
Система должна иметь возможность
гибкой
настройки
при
изменении
внешней среды и конкретных задач
пользователя без замены модулей.
M
R6.4.
Система
должна
быть
высоко
масштабируемой и позволять работать в
системе неограниченному количеству
пользователей.
Ограничения
могут
обуславливаться только техническими
характеристиками оборудования, а не
M
Раздел VI. Технические требования
343
характеристиками Системы
R6.5.
Все
функциональные
возможности
системы должны быть разработаны в виде
сервисов.
M
R6.6.
Веб-сервисы Системы должны
разработаны в соответствии с
архитектурой.
M
R6.7.
При реализации сервисов взаимодействия
обязательно придерживаться стандарта
МЗСР РК. Касающегося взаимодействия
информационных систем
М
R6.8.
Система
должна
предусматривать
возможность конструирования шаблонов
утвержденных
медицинских
форм,
доступных в пределах самого решения,
которые могут быть автоматизированы
без программирования или внесения
изменений в программный код.
M
R6.9.
Система
должна
обеспечивать
разрешение
конфликтов
при
параллельной
обработке
объектов
системы.
M
R6.10.
Требования
интерфейсу
M
R6.10.1
Интерфейс должен быть рассчитан на
к
быть
СОА
пользовательскому
M
Раздел VI. Технические требования
344
преимущественное
использование
манипулятора типа «мышь», то есть
управление
системой
должно
осуществляться с помощью набора
экранных меню, кнопок, значков и тому
подобных элементов
R6.10.2
Клавиатурный режим ввода должен
использоваться главным образом при
заполнении
и/или
редактировании
текстовых и числовых полей экранных
форм.
Также
должны
быть
предусмотрены горячие клавиши для
перехода между заполняемыми полями.
M
R6.10.3
Эргономические решения и дизайн
интерфейсов по возможности должны
быть едиными для всех компонентов и
модулей Системы
M
R6.10.4
Пользовательский интерфейс Системы
должен
быть
многоязычным
и
организован с поддержкой не менее чем
государственного
(Казахсткого)
и
русского языков. Исключения могут
составлять только системные сообщения,
не
подлежащие
локализации
или
стандартные
административные
приложения,
входящие
в
состав
общесистемного
программного
обеспечения
M
Раздел VI. Технические требования
345
R6.10.5
Должен быть обеспечен доступ к
электронному
комплекту
эксплуатационной документации
M
R6.10.6
В системе должна быть реализована
контекстно-зависимая
справочная
система, доступная из любых страниц
веб-приложения, где должны быть
представлены ссылки на информацию
(Руководство пользователя, инструкции и
др.) для работы, с возможностью
конфигурации
без
привлечения
Потенциального Поставщика на уровне
Покупателя;
M
R6.10.7
В пользовательском интерфейсе Системы
должно быть предусмотрено визуальное
выделение
на
экране
атрибутов,
доступных оператору только для чтения
M
R6.10.8
В пользовательском интерфейсе Системы
должно быть предусмотрено визуальное
выделение
на
экране
атрибутов,
обязательных для заполнения
M
R6.10.9
Система
должна
обеспечивать
корректную
обработку
аварийных
ситуаций,
вызванных
неверными
действиями пользователей, неверным
форматом
или
недопустимыми
значениями
входных
данных.
В
указанных случаях Система должна
M
Раздел VI. Технические требования
346
выдавать пользователю соответствующие
сообщения, после чего возвращаться в
рабочее состояние, предшествовавшее
неверной (недопустимой) команде или
некорректному вводу данных
R6.10.10
Система
не
должна
позволять
дублирование и повторный (ошибочный)
ввод однородной информации. Система
должна
обеспечивать
исключение
дублирования и повторного ввода
информации,
содержащейся
в
государственных
базах
данных
и
информационных
системах
государственных органов.
M
R6.10.11
Система должна обеспечивать форматнологический контроль вводимых данных.
Под форматно-логическим контролем
вводимых данных понимается контроль
на формат и содержание вводимых
данных. При работе Системой должна
быть
предусмотрена
защита
от
ошибочных действий:
выбор только доступных для
пользователя (в соответствии с правами
доступа) функций;
ввод только доступных для
пользователя (в соответствии с правами
доступа) значений;
- ввод данных только определенного
M
Раздел VI. Технические требования
347
формата (например, невозможность ввода
символьных данных в поле формата
«Дата» или «Число»).
R7
Требования к взаимодействию Системы
R7.1.
Общие
требования
интероперабельности Системы
R7.1.1
Решения и приложения Системы должны
соответствовать
стандартам
интероперабельности, в том числе
национальным стандартам и принятым
международным
стандартам,
перечисленным в этой главе (и в этом
документе).
к
M
Компоненты
Системы
должны
соответствовать
национальным
инструментам семантики:
o Справочники
и
классификаторы
o Требования к
справочников
R7.1.2
сервисам
M
o Требования к регистрам и
сервисам регистров
o Требования к управлению
ресурсами
и
бухгалтерскому учету
Детали
по
требованиям
для
этих
Раздел VI. Технические требования
348
инструментов приведены в этом разделе
ниже (R7.3).
R7.2.
Совместимость со стандартами
R7.2.1
Компоненты Системы должны быть
совместимы не менее чем со следующими
стандартами МЗСР РК:
1)
Стандартные
требования
к
электронному
паспорту
здоровья
(требующий соблюдения EN 13940)
2) Стандартные требования к электронной
медицинской
записи
(требующий
соблюдения EN13940)
3)
Стандартные
требования
к
идентификации действующих сторон
здравоохранения,
используемых
в
системах электронного здравоохранения
4)
Технические
требования
к
взаимодействию (передаче сообщений) с
информационными
системами
электронного здравоохранения
5)
Регламент
по
обеспечению
информационной безопасности
6) Стандартные требования к единому
классификатору лекарственных средств,
изделий медицинского назначения и
медицинской техники
7) Стандартные требования к реализации
и
регулированию
электронных
направлений
M
Раздел VI. Технические требования
349
8)
Регламент
взаимодействия
заинтересованных сторон с целью
обеспечения
интероперабельности
информационных систем и управления
информационными потоками
9) Стандарт регулирования ведения
рецептов в электронном формате
10) Стандарт управления электронными
процессами диагностических
исследований и лечебных процедур
11) Стандарт регулирования электронной
профилактики заболеваний
Указанные стандарты и нормативные
документы
доступны
по
ссылке
https://www.mzsr.gov.kz/taxonomy/term/619
R7.2.2
Компоненты Системы должны быть
совместимы
со
следующими
международными стандартами:
a. EN
13940
(в
части
необходимости
соответствия
стандартам
ЭПЗ и ЭМЗ)
b. HL7 (ISO/HL7 27831), HL7
(v2 или V3 или FHIR);
c. HL7 CDA R2
27932)
d. DICOM
(ISO/ HL7
M
Раздел VI. Технические требования
350
R7.2.3
Система
должна
соответствовать
требованиям
стандартам
по
информационной безопасности:
 СТ РК ИСО/МЭК 27001-2008
«Методы и средства обеспечения
безопасности системы управления
информационной безопасностью.
Требования»;
 СТ РК ИСО/МЭК 27002-2009
«Информационная
технология.
Средства
обеспечения.
Свод
правил по управлению защитой
информации».
R7.3.
Требования
к
совместимости
национальными
идентификаторов
стандартными
классификаторами
справочниками
R7.3.1
Компоненты
Системы
должны
поддерживать
и
соответствовать
требованиям
к
национальным
идентификаторам:
- Идентификатор Пациентов
Идентификатор
организаций
здравоохранения
- Идентификатор медработников
- Идентификатор медицинской техники
M
R7.3.2
Компоненты
поддерживать
M
M
с
и
/
Системы
должны
и
соответствовать
Раздел VI. Технические требования
требованиям,
как
минимум
по
следующим
классификаторам
и
справочникам:
1)
Национальный
классификатор
лекарственных средств и медицинских
материалов (картированный к АТС- DDD
)
2) Классификатор медицинских услуг (на
основе МКБ-9, раздел по услугам и .3)
3)
Классификатор
результатов
лабораторных исследований
4) Классификатор услуг и их стоимости
5) Классификатор диагнозов (МКБ-10)
6) Классификатор ПМСП (ICPC-2)
7) Картирование ICPC-2 и МКБ-10
8)
SNOMED,
(только
для
цели
кодирования связи между Системой и
Репозиторием ЭПЗ)
9) Для управления диагностическими
услугами
улучшенная
система
классификации, должна быть определена
на более позднем этапе;
10) Реализованная МЗ, национальная
система
КЗГ
для
классификации
пациентов
(при
оказании
специализированной помощи);
11) Классификатор регистров целевых
групп пациентов (Диспансерные группы);
12) Тарификатор медицинских услуг;
13) Специальностей здравоохранения;
14) Список должностей
351
Раздел VI. Технические требования
352
R7.4.
Требования
к
совместимости
соответствию данных
/
R7.4.1
Компоненты
Системы
должны
обеспечивать связь между Системой и
Платформой, содержащей Репозиторий
ЭПЗ, основываясь на следующих данных:
- минимальный набор данных для ЭПЗ
(приводится
в
Приложении
к
Национальному
стандарту
ЭПЗ
и
Национальному стандарту ЭМЗ)
другие
данные,
не
покрытые
семантическими
стандартами,
но
необходимыми согласно НПА МЗСР РК,
такие как Прикрепленные специальные
записи (документы, основанные на CDA)
M
R7.4.2
Система должна обеспечивать доступ к
данным, хранящимся в Репозитории ЭПЗ,
в соответствии с 2 типами ЭПЗ: Полный
ЭПЗ, Краткий ЭПЗ. Подробности описаны
в Национальном стандарте ЭПЗ
M
R7.4.3
Данные передаются между Системой и
Репозиторием ЭПЗ в формате CDA
M
R7.4.4
Система
должна
предоставлять
возможность
передачи
данных
в
Репозиторий ЭПЗ на основе кодов ICPC2, которые используются в посещениях (и
контактах в целом) и картированы к МКБ10 для целей сбора статистики. В
M
Раздел VI. Технические требования
353
информационных системах ЭМЗ (кроме
систем ЭПЗ/ ПМСП) специалисты
используют для кодирования диагностики
МКБ-10, и картирование в обратном
направлении не является обязательным,
лишь желательным.
R7.4.6
Система
должна
быть
достаточно
открытой,
чтобы
быть
способной
обеспечить
интероперабельность
с
существующими
ИС
МЗСР
РК,
приложениями и сервисами (см. также
раздел 1.4.2).
R7.5.
Требования к информационному обмену
R7.5.1
Система должна взаимодействовать с
национальной
системой
ЭПЗ
в
соответствии
с
Национальными
стандартами ЭПЗ и ЭМЗ.
M
R7.5.2
Система должна поддерживать (как
минимум)
взаимодействие
со
следующими
наборами
сервисов
электронного здравоохранения:
 Сервисы репозитория ЭПЗ;
 Сервисы справочной информации;
 Сервисы регистрации и регистров;
 Сервисы
Клинической
Номенклатуры и классификации
данных;
M
M
Раздел VI. Технические требования
354
 Сервисы
безопасного
обмена
информацией
и
обмена
сообщениями;
 Сервисы
идентификации
и
аутентификации;
- Сервисы мониторинга и аудита для
информационного обмена.
Система должна соответствовать как
минимум следующим профилям IHE:
a) Инфраструктурные профили IHE:
 ATNA;
 XDS.b;
R7.5.3
 PDQ;
M
 PIX;
b) Лабораторные профили IHE:
 LBL;
 LWT.
R7.5.4
Система должна обеспечить возможности
взаимодействия/интеграции
с
использованием как минимум следующих
протоколов и спецификаций:
a. Коммуникацию через SOAP (и
сообщения SOAP с приложением),
REST,
Message
Transmission
Optimization Mechanism;
b. Поддержка
стандартов
и
М
Раздел VI. Технические требования
спецификаций веб-сервисов
Security,
WS-Addressing,
Reliable
Messaging,
coordination, WS-Transaction,
Secure Conversation);
355
(WSWSWSWS-
c. Соответствовать стандартам XML
(XML, XSL, ebXML, и др.);
d. Поддерживать SSO и контроль
доступа через SAML v2, JWT;
e. Поддерживать общие стандарты,
такие как HTTP, HTTPS, TCP/IP,
протоколы защищённых сокетов
(SSL v3) и TLS;
f. Позволить использование WSDL,
WADL;
g. X.509;
h. Цифровые подписи (ЭЦП НУЦ
РК).
R7.5.5
Система должна поддерживать кодировку
UTF8.
М
R7.5.6
Система должна взаимодействовать с
сервисами Платформы при скорости
канала 1 Мб/с и времени отклика не более
100 мс
М
R7.5.7
Система должна взаимодействовать с
сервисами Платформы в части:
М
Раздел VI. Технические требования
356
 передачи/получения уведомлений
и других сведений, носящих
информационный характер на
шлюз
«электронного
правительства»;
 отправки SMS-уведомлений и
других
видов
рассылки
посредством СМС-шлюза системы
Мобильное правительство;
 отправки
электронных
писем
пациентам посредством единой
электронной почтовой системой;
 получения
сведений
о
доверенностях из государственной
информационной системы Единая
нотариальная
информационная
система;
 получения сведений по записям на
прием к врачу;
 получения
минимальной
информации о сотруднике.
R8
Использование национальных ресурсов
электронного
здравоохранения
и
инструментов Платформы
R8.1.
Система
должна
быть
способна
функционировать в соответствии с общей
архитектурой
электронного
здравоохранения (Рисунок 2)
M
Раздел VI. Технические требования
357
R8.2.
Система
должна
быть
способна
использовать функционал и веб-сервисы,
опубликованные на национальном уровне
для
взаимодействия
с
ресурсами
электронного здравоохранения
M
R8.3.
Система
должна
быть
способной
использовать
репозиторий
ЭПЗ,
национальные классификаторы и индексы
(как минимум Главный индекс пациента,
индекс
подразделений
медицинских
организаций, индес сотрудников, индекс
зданий,
адресный
индекс,
индекс
автотранспорта, индекс медицинской
техники), аналитическое хранилище и
другие
национальные
ресурсы,
необходимые для интеграции «под-ключ»
согласно
национальным
стандартам
(перечисленные в Приказе МЗ РК №75 от
10.02.2014 года)
M
R8.4.
Система должна поддерживать локальные
копии национальных ресурсов и быть
способной синхронизировать их на
регулярной основе (в соответствии с
настраиваемым графиком) или онлайн.
Система должна содержать только
информацию, касающуюся деятельности
медицинской организации. Например,
Главный индекс пациентов должен
содержаться локально только для перечня
M
Раздел VI. Технические требования
358
пациентов, обслуживающихся в данной
организации.
R9
Взаимодействие
со
сторонами,
вовлеченными в процесс сертификации
R9.2.
Поставщик
системы
должен
взаимодействовать
с
Поставщиком
платформы, Организацией и МЗСР РК в
целях тестирования и сертификации
интероперабельности с национальными
ресурсами и сервисами.
M
R9.3.
Поставщик
системы
должен
координировать
взаимодействие
вовлеченных сторон в соответствии с
рисунком 3. Сертификация заключается в
проверке
установленной системы на
соответствие
требованиям
R7.2.
Покупатель уполномочит специальную
комиссию,
которая
совместно
с
Поставщиком Платформы и поставщиком
данной системы, проведут тесты в
соответствии стандартам МЗСР РК, на
соответствие
требованиям
по
интероперабельности в соответствии с
национальными станддартами, в том
числе на способность корректного
взаимодействия поставленной системы, с
национальными
ресурсами
предоставленными в рамках платформы.
M
Раздел VI. Технические требования
359
R9.4.
На этапе проектирования Системы
(действие 4.4) Поставщик Системы
должен
соблюдать
требования
«Регламентов разработки веб-сервисов» и
«Требования
к
взаимодействию
с
Репозиторием ЭПЗ» предоставляемые
поставщиком Платформы. Поставщик
Системы
может
запросить
дополнительную
информацию
при
необходимости
для
разработки
взаимодействия с ресурсами электронного
здравоохранения.
M
R9.5.
На этапе тестирования/сертификации
(действие 4.6) поставщик Системы
должен
соблюдать
требования
и
стандарты электронного здравоохранения
R7.2
M
R9.6.
Поставщик
обязан
сертифицировать
систему до приемки в эксплуатацию.
M
R9.7.
В случае, возникновения обстоятельств не
позволяющих выполнить требование R9.6
и происходящих не по вине Поставщика,
Акты приемки Системы могут быть
подписаны без сертификации. При этом
поставщик
Системы
обязуется
сертифицировать
систему
когда
появляются условия сертификации, без
дополнительных затрат со стороны
Покупателя.
M
Раздел VI. Технические требования
360
R10
Требования к поставщикам
R10.1.
Поставщик будет поставлять свою
собственную Систему (компоненты и
продукты составляющие ее) или будет
уполномочен Разработчиком/владельцем
этой Системы (компонентов и продуктов
составляющих ее) на обеспечение,
разработку, установку, сопровождение
продукции в соответствии с настоящим
тендером.
M
R10.2.
Поставщик будет проводить обучение в
стране
клиента,
связанное
с
использованием и администрированием
Системы, а также для всех разработанных
и установленных продуктов. Языками
обучения будет государственный и
русский. Детали по обучению приведены
в R12.2
M
R10.3.
Поставщик должен иметь офис в стране
Покупателя
или
иметь
партнера,
зарегистрированного
в
качестве
юридического лица в стране Покупателя,
имеющего официальный статус партнера
разработчика
/
поставщика,
или
имеющего соглашение о консорциуме,
связанном
с
этим
конкретным
контрактом. Это необходимо во время
реализации, развертывания, обучения и
M
Раздел VI. Технические требования
гарантийного срока для гладкой
надежной реализации контракта.
R10.4.
361
и
Поставщик должен иметь команду
реализации проекта, состоящую не менее
чем из следующих специалистов (в случае
необходимости, две позиции могут быть
приняты одним специалистом при
условии, что навыки будут доказаны, но
не более чем 2 позиции на специалиста):
1) Бизнес-аналитик, имеющий опыт
работы не менее 3 лет в ИТ проектах
электронного здравоохранения и опытом
работы хотя бы в одном аналогичном
проекте;
2)
Менеджер
управления
проекта
(руководитель команды), имеющий опыт
работы не менее 3 лет в управлении
проектами и опыт работы более 1 года, с
предлагаемым решением и должен иметь
сертификат
управления
проектами
(например, PMP или IPMI не менее Level
B);
3) Специалист СУБД имеющий, не менее
3 лет опыта работы с СУБД;
4) Специалисты с опытов работы со
стандартами не менее 2 лет: HL7, DICOM,
CDA (R2), IHE;
5)
Дизайнер
пользовательского
интерфейса, имеющий опыт работы не
менее 3 лет;
M
Раздел VI. Технические требования
362
6) Технический писатель, имеющий опыт
работы не менее 2 лет;
7) Специалист по связям, имеющий опыт
работы в данной области не менее 3 лет
общего опыта ИТ, с отличным владением
английским, русским и
казахским
языками;
8)
Специалист
по
тестированию,
имеющий не менее 3 лет опыта
тестирования ПО;
9) Специалист по обучению, имеющий не
менее 3 лет опыт в проведении обучения;
Все предлагаемые специалисты должны
иметь высшее образование в ИТ или
взаимосвязанных
областях,
степень
магистра предпочтительна. Поставщик
должен
представит
перечень
специалистов, с приложением резюме,
сертификатов для доказательства опыта
работы и квалификации.
R10.5.
Поставщик должен представить все
документы
(патенты,
лицензии,
свидетельства
о
государственной
регистрации прав на объект авторского
права и т.п.) на Систему (для всех
компонентов
и
продуктов),
демонстрирующие
разрешение
владельцев использовать продукты для
данного контракта или демонстрирующие
M
Раздел VI. Технические требования
363
владение продуктами.
R10.6.
План - график оказания услуг должен
быть согласован с уполномоченной
организацией Покупателя и подписан
Покупателем в течение 20 (двадцати)
рабочих дней после подписания договора.
Поставщик
должен
своевременно
оказывать
услуги
согласно
утвержденному план-графику.
M
R10.8
Производители ПО должны иметь как
минимум один сертификат из следущего
перечня: Capability Maturity Model
Integration (CMMI), ISO 9000 series, СТ РК
ISO 9001:2009 или эквивалент по качеству
менеджмента (Участник торгов должен
предоставить
копии
сертиификатов
соответствия выданных уполномоченным
органом).
M
R10.9
Поставщик
должен
обеспечить
обслуживание
и
техническую
и
гарантийную
поддержку,
включая
предоставление новых версий продуктов
в соответствии с R12.3 и R12.4.
M
R10.10
Поставщик
должен
подготовить
соответствующие руководства для всех
компонентов Системы на английском,
казахском и русском языках.
M
Раздел VI. Технические требования
R10.11
Поставщик должен иметь доказанный
опыт работы с одним или несколькими
стандартами,
используемыми
в
настоящем документе: HL7 (v2, V3,
FHIR), CDA (R2), IHE.
R10.13
Поставщику Системы будет предоставлен
доступ
к
национальным
ресурсам
электронного здравоохранения
только
после того, как параллельный контракт
будет успешно реализован. В целях
облегчения параллельной реализации
необходимо
синхронизировать/координировать
совместные действия с поставщиком
Платформы. В случае, возникновения
обстоятельств
не
позволяющих
выполнить
требования
по
взаимодействию с Платформой, ввиду
задержки выполнения котракта по
поставке
Платформы,
поставщик
Системы
обязуется
реализовать
взаимодействие, когда появятся условия,
без дополнительных затрат со стороны
Покупателя.
R11
Общие технические требования к Системе
R11.1.
Система быть способной работать с
локального сервера через локальную сеть,
используемую одной ЛПО
364
M
M
M
Раздел VI. Технические требования
365
R11.2.
Серверная часть
Системы должна
поддерживать работу как минимум в
операционных
системах
семейства
Windows.
M
R11.3.
Клиентская часть Системы должна
поддерживать работу как минимум в
операционных
системах
Windows
(2008/VISTA/7/8) (x86/x64)
M
R11.4.
Для сохранения информации в Системе
должна использоваться реляционная база
данных.
M
R11.5.
База
данных
Системы
должна
поддерживать
стандартный
SQL,
совместимый
со
стандартом
ANSI/ISO/IEC 9075-1992
M
R11.6.
Поставщик
обязан
обеспечить
обслуживание и техническую поддержку,
включая предоставление новых версий
продуктов
до
истечения
срока
гарантийного обслуживания
M
R11.7.
Система
должна
предоставлять
возможность
функционирования
на
удаленной инфраструктуре и в облачной
(виртуализированной)
операционной
среде
M
R11.8.
Система
M
должна
предоставлять
Раздел VI. Технические требования
возможность
аутентификации
использование технологии SSO
366
с
R12
Спецификация услуг
R12.1.
Требования к наследованию данных и
функционала.
R12.1.1
В случае поставки и внедрения Системы
отличной от эксплуатируемой заказчиком
Поставщик
осуществляет
полный
комплекс
необходимых
работ
по
наследованию данных и функционала,
используемых Покупателем модулей
информационной
системы
с
подключением к Системе используемых
Покупателем программных и технических
средств автоматизации, медицинского и
лабораторного оборудования.
M
R12.1.2
Все затраты, связанные с обеспечением
наследования данных и функционала
несет Поставщик.
M
R12.2.
Обучение и учебные материалы
R12.2.1
Поставщик должен подготовить учебный
план для обучения следующих групп:
e) пользователи системы;
f) администраторы системы;
M
Раздел VI. Технические требования
367
g) разработчики,
h) администраторы баз данных.
Учебный план и учебные материалы по
каждой группе должны быть согласованы
с Покупателем до начала обучения.
R12.2.2
Поставщик
должен
обеспечить
оборудование,
презентационные
материалы и пособия, необходимые для
обучения
M
R12.2.3
Поставщик Системы должен представить
учебные материалы в форме руководств,
учебных книг и презентаций, баз знаний
на государственном и русском языках.
M
R12.2.4
Поставщик должен провести обучение как
минимум 80 часов для каждой группы
администраторов
системы,
разработчиков, администраторов баз
данных и 20 часов для пользователей
каждой медицинской организации, в
которой проводится внедрение Системы.
Количество часов может быть увеличено
и должно быть достаточно для передачи
знаний и навыков.
M
R12.2.5
Поставщик должен проводить отдельное
обучение
для
пользователей,
администраторов системы, разработчиков
и
администраторов баз данных.
M
Раздел VI. Технические требования
368
Индикативное
число
обучаемых
определяется путем умножения на 2
общего количества автоматизированных
рабочих мест из Приложения 2. Место
обучения
–
юридический
адрес
медицинской организации – бенефициара
. Группы обучающихся должны включать
не более 10 человек
R12.2.6
Учебный план для группы (а) пользователи
системы
должен
содержать
детальное
разъяснение
автоматизированных бизнес процессов,
использование
всех
компонентов
системы, подробное описание функций и
взаимодействий
между
различными
пользователями и ролями; отчётность и
другая
необходимая
информация.
Обучение
также
будет
содержать
практические тренинги для понимания
материала.
M
R12.2.7
Учебный план для группы (b) администраторы системы - должен
содержать
описание
инструментов
администрирования
компонентов
системы, включая важные вопросы
сопровождения системы, и аспекты
технической поддержки.
M
R12.2.8
Поставщик должен провести для группы
(c) разработчики один вводный курс и
M
Раздел VI. Технические требования
369
один курс повышения квалификации по
предоставляемым средствам разработки и
компонентам, предусмотренных в рамках
данного контракта.
R12.2.9
Поставщик должен провести для группы
(d) администраторы баз данных один
вводный курс и один курс повышения
квалификации по предоставляемой СУБД.
M
R12.2.10
Обучение для групп (a) - (d) должно
проводиться на русском языке или на
госсударственном языке по требованиям
Покупателя.
M
R12.2.11
Все тренинги проводятся тренерами в
Астане или в другом месте, указанном
Покупателем.
M
R12.2.12
Для всех проведенных тренингов,
Поставщик
должен
провести
соответствующее
тестирование
и
выдавать сертификаты.
M
R12.2.13
Вышеуказанное
количество
и
продолжительность обучения являются
минимальными требованиями. Поставщик
по запросу Покупателя может увеличить
эти величины (в часах) для достижения
адекватного
уровня
навыков
для
персонала без дополнительных затрат со
стороны Покупателя. Во время этапа
I
Раздел VI. Технические требования
370
подготовки проекта точное число часов,
групп и содержания курсов будут
согласованы с Поставщиком.
R12.3.
Служба поддержки пользователей
R12.3.1
Поставщик должен организовать службу
поддержки
пользователей
для
консультирования
по
вопросам,
возникающим в процессе эксплуатации,
на все время внедрения и обеспечения
гарантийного обслуживания.
M
R12.3.2
Техническая поддержка Системы и её
пользователей должна осуществляться
Поставщиком в режиме 24 часа в сутки, 7
дней в неделю, в течение 2 лет с момента
подписания актов ввода Системы в
эксплуатацию.
M
R12.4.
Гарантийный сервис
R12.4.1
Поставщик Системы будет обеспечивать
гарантийное обслуживание Покупателя в
течение 3 лет, начиная сразу после
согласования Покупателем Акта приемки.
M
R12.4.2
Поставщик
должен
обеспечить
разрешение запросов:
c) для
критичных
проблем,
касающихся
работоспособности
M
Раздел VI. Технические требования
371
Системы
и
ведущих
к
повреждению данных, проблема
должна быть решена не более чем
за 2 часов;
d) для не критичных проблем не
более 2 дней.
R12.4.3
Гарантийное обслуживание включает в
себя, но не ограничивается, следующими
категориями услуг:
- Исправление ошибок в Системе;
- Помощь Организации в правильном
исправлении всех проблем с данными,
возникающими в результате ошибочной
функции приложений;
- Обеспечение технической поддержки в
настройке приложения или изменения
параметров по умолчанию;
- Оказание необходимой технической
помощи квалифицированному персоналу
и переподготовка, если выявлено, что они
не могут решить все проблемы после
полученной подготовки;
M
R12.4.4
Формы вмешательства могут быть одним
из следующих наиболее подходящих с
точки зрения качества и эффективности:
- Телефонные звонки;
M
Раздел VI. Технические требования
372
- По электронной почте;
- Skype или другие Video Messenger;
- Удаленный доступ к пользователю;
- Работа на месте.
R12.4.5
Поставщик должен обеспечить в течении
гарантийного
срока
группу
консультантов, доступных в стране
Покупателя в том числе одного
менеджера и как минимум одного
технического
специалиста,
и
предоставить
всех
необходимых
специалистов
на
расстоянии
для
дистанционной
помощи
(по
мере
необходимости).
M
R12.4.6
Суммарное время простоя Системы по
причинам,
связанным
с
её
работоспособностью
не
должно
превышать 24 часов в год.
M
R12.4.7
Время однократного простоя Системы по
причинам,
связанным
с
её
работоспособностью
не
должно
превышать 2 часов.
M
R13
Требования к документации
R13.1
Поставщику необходимо предоставить
следующий пакет документов:
M
Раздел VI. Технические требования
373
- Программа и методика испытаний;
- Формуляр
(основные
характеристики, комплектность и
сведения
об
эксплуатации
депонируемого
программного
продукта);
- Описание
наиболее
распространенных
ошибок
и
способов их устранения;
- Описание структуры базы данных;
- Руководство
по
установке
программного обеспечения;
- Руководство администратора;
- Руководство пользователя.
R13.2
Языками документов должны быть как
минимум государственный и русский.
M
R13.3
Поставщик должен предоставить 5
комплектов документации в бумажном и
электронном виде на английском, русском
и казахском языках.
Электронные
версии
должны
поддерживать возможность контекстового
поиска.
M
R13.4
Поставщик
должен
подготовить
информационную систему и нормативнометодическую
документацию
к
M
Раздел VI. Технические требования
374
проведению аттестации на соответствие
требованиям
информационной
безопасности согласно со статьей 5
Закона Республики Казахстан от 11
января 2007 года «Об информатизации» и
Постановлением
Правительства
Республики Казахстан от 30 декабря 2009
года № 2280 «Об утверждении Правил
проведения аттестации государственных
информационных
систем
и
негосударственных
информационных
систем,
интегрируемых
с
государственными
информационными
системами,
на
соответствие
их
требованиям
информационной
безопасности и принятым на территории
Республики Казахстан стандартам» и к
вводу в эксплуатацию в соответствии со
статьей 17 Закона Республики Казахстан
от
11
января
2007
года
«Об
информатизации».
R14
Тестирование системы
гарантии качества
и
требования
R14.1
Предпусковые работы
R14.1.1
Поставщик Системы должен выполнять
стандартные установочные тесты для
проверки корректной установки Системы.
M
Раздел VI. Технические требования
375
R14.1.2
Поставщик должен предложит в рамках
технического предложения список тестов,
условий испытаний, критериев успеха и
другого для испытаний Системы.
M
R14.1.4
Поставщик Системы проведет поэтапные
детальные испытания, в том числе тесты
производительности, времени отклика,
пропускной
способности,
Системы
совместно
с
организацией,
уполномоченной Покупателем, согласно
тестам предоставленным Поставщиком.
M
R14.1.5
Поставщик
должен
провести
демонстрацию Системы с участием
представителей
Покупателя
и
организацией,
уполномоченной
Покупателем
согласно
сценарию
испытаний Системы на любом этапе
контракта.
М
R14.1.6
Поставщик должен оформить результаты
демонстрации в виде Протокола о
проведении демонстрации по форме,
согласованной с Покупателем. Протокол
должен
быть
подписан
всеми
участниками демонстрации.
Место
проведение
демонстрации
согласовываются с Покупателем и
организацией
уполномоченной
Покупателем.
М
Раздел VI. Технические требования
376
R14.1.7
Поставщик должен устранять замечания,
полученные
в
ходе
проведения
демонстраций, и проводить повторные
демонстрации до получения протокола об
успешном проведении демонстрации.
Сроки
устранения
замечаний
согласовываются с Покупателем.
М
R14.1.8
Тестирование должно осуществляться в
соответствии с одним из стандартов IEEE
829/1009, BS 7925, ISO/AS 9100 и
разработанным документом «Программа
и методика испытаний» СТ РК 1089-2002.
М
R14.1.9
Поставщик
должен
Систему в соответствии
Accessibility Guidelines
Поставщик
должен
подробную информацию
тестировании.
М
R14.1.10
Поставщик
должен
протестировать
Систему по безопасности в соответствии с
OWASP Топ 10 уязвимости. Поставщик
должен
представить
подробную
информацию о результатах тестировании.
М
R14.1.11
Поставщик
должен
согласовать
с
Покупателем сценарий тестирования и
предоставить отчёт по результату каждого
тестирования.
М
протестировать
с Web Content
(WCAG) 2.0.
представить
о результатах
Раздел VI. Технические требования
377
R14.2
Приемка в эксплуатацию
R14.2.1
Акт приемки Системы подписывается на
основании бесперебойной работы при
нормальных условиях эксплуатации для
Системы в течении 3 месяцев. В случае
выявления ошибок функционирования в
данный период Поставщик должен внести
необходимые изменения и провести
повторную эксплуатацию Системы
в
течении 3 месяцев. Под ошибками
фунционирования
понимаются
критические
ошибки,
которые
не
позволяют эксплуатировать Систему
M
R14.2.2
Поставщик должен начать необходимую
работу для устранения дефектов или
повреждений в течение 10 рабочих дней
для
некритичных
ошибок.
Для
критических ошибок поставщик должен
начать
работу,
необходимую
для
устранения дефектов или повреждений в
течение 3 рабочих дней, обеспечить
фиксацию времени и отчет о фиксации
хода каждый час в течение оперативного,
а также гарантийного срока.
Критические ошибки: система не работает
или работает не стабильно. Важная
функциональная
составляющая
не
работает или недоступна. Потеря данных
или прерывание основного потока
M
Раздел VI. Технические требования
378
процесса. Компонент системы непригоден
из-за
сбоя
или
неправильной
функциональности. Пользователи
не
могут выполнять любую работу.
R14.2.3
Обязательным условием приемки в
эксплуатацию является сертификация
системы в соответствии с требованиями
R9
R15
Требования к обеспечению контроля со
стороны Покупателя
R15.1
Поставщик должен с периодичностью,
определенной
в
план-графике,
предоставлять Покупателю отчет о
проделанной работе за истекший период.
М
R15.2
Отчет должен содержать информацию о
выполненных работах Поставщика за
отчетный период, в соответствии с
утвержденным план-графиком, включая
услуги по гарантийной поддержке, по
СТП с приложением всей утвержденной в
процессе
реализации
договора
за
отчетный период документации, включая
официальную переписку, в бумажном и
электронном виде (в формате pdf).
М
R15.3
Отчет должен
организацией,
Покупателем.
М
быть
согласован с
уполномоченной
M
Раздел VI. Технические требования
R15.4
Покупатель может в любой момент
исполнения договора проводить контроль
исполнения Поставщиком мероприятий и
качества услуг по договору.
379
М
Раздел VI. Технические требования
380
H. ПРИЛОЖЕНИЯ
Приложение 1
Права доступа ролей к функциям модулей
1.
Модуль «Регистратура»
Роли
1.1.
Ведение графиков работы врачей,
выполнения услуг, работы аппаратов
Составитель графиков
Медицинский регистратор
Старшая медицинская сестра
Заведующий отделением
поликлиники
1.2.
Запись пациента на прием с выдачей
талона на прием
Пациент (через Интернет)
Участковый врач
Врач профилактического отделения
Профильный специалист
Медицинский регистратор
1.3.
Ведение журнала вызовов на дом
Медицинский регистратор
Участковый врач
Профильный специалист
Заведующий отделением
поликлиники
Старшая медицинская сестра
1.4.
Ведение журнала активов (вызовы на
дом по инициативе медицинских
работников)
Медицинский регистратор
Участковый врач
Заведующий отделением
поликлиники
Старшая медицинская сестра
1.5.
Ведение первичной учетной
документации на уровне регистратуры в
соответствии с действующими
нормативными правовыми актами РК
Медицинский регистратор
Участковый врач
Врач профилактического отделения
Профильный специалист
Заведующий отделением
поликлиники
Старшая медицинская сестра
1.6.
Формирование аналитических форм на
уровне регистратуры, а также
статистических таблиц в соответствии с
действующими нормативными
Медицинский регистратор
Участковый врач
Врач профилактического отделения
Профильный специалист
Раздел VI. Технические требования
правовыми актами РК
381
Главный врач
Медицинский статистик
поликлиники
Заведующий отделением
поликлиники
Старшая медицинская сестра
2.
Модуль «Участковый врач»
2.1.
Ведение амбулаторной карты пациента
Участковый врач
Врач профилактического отделения
Профильный специалист
Медсестра участкового врача
Профильный специалист
Заведующий отделением
поликлиники
2.2.
Создание внутренние (в пределах данной
медицинской организации) и внешние (в
другие медицинские организации)
направления на консультативнодиагностические услуги
Участковый врач
Врач профилактического отделения
Профильный специалист
Медсестра участкового врача
Заведующий отделением
поликлиники
2.3.
Оформление плановой госпитализации
(круглосуточный стационар и
стационарозамещающие технологии)
Участковый врач
Врач профилактического отделения
Профильный специалист
Медсестра участкового врача
Заведующий отделением
поликлиники
2.4.
Формирование врачебных назначений
Участковый врач
лекарственных средств и/или процедур и Профильный специалист
манипуляций
Заведующий отделением
поликлиники
2.5.
Ведение первичной учетной
документации на уровне участкового
врача в соответствии с действующими
нормативными правовыми актами РК
Участковый врач
Врач профилактического отделения
Профильный специалист
Медсестра участкового врача
Заведующий отделением
поликлиники
2.6.
Формирование аналитических форм на
уровне участкового врача, а также
статистических таблиц в соответствии с
Участковый врач
Врач профилактического отделения
Профильный специалист
Раздел VI. Технические требования
382
действующими нормативными
правовыми актами РК
Медсестра
Заведующий отделением
поликлиники
Медицинский статистик
поликлиники
2.7.
Ведение учета листов временной
нетрудоспособности.
Участковый врач
Профильный специалист
Заведующий отделением
поликлиники
2.8.
Взаимодействие с ИС МЗСР РК в части
передачи информации о выполненных
услугах, клинической информации,
направлениях, назначениях в
соответствии с действующими
нормативными правовыми актами РК.
3.
Модуль «Ведение профилактических
осмотров»
3.1.
Формирование контингентов
подлежащих профилактическим
осмотрам целевых групп
населения(скрининг) и учет их
проведения в соответствии с
действующими нормативными
правовыми актами РК
Участковый врач
Врач профилактического отделения
Профильный специалист
Медсестра профилактического
отделения
Заведующий отделением
поликлиники
3.2.
Учет других видов профилактических
осмотров
Участковый врач
Врач профилактического отделения
Профильный специалист
Медсестра профилактического
отделения
Заведующий отделением
поликлиники
3.3.
Ведение первичной учетной
документации на уровне врача в
соответствии с действующими
нормативными правовыми актами РК
Участковый врач
Врач профилактического отделения
Профильный специалист
Медсестра профилактического
отделения
Заведующий отделением
поликлиники
4.
Модуль «Профильный специалист»
Раздел VI. Технические требования
383
4.1.
Ведение амбулаторной карты пациента
Профильный специалист
Медсестра специалиста
Заведующий отделением
поликлиники
4.2.
Создание направлений на
консультативно-диагностические услуги
внутренние (в пределах данной
медицинской организации) и внешние (в
другие медицинские организации)
Профильный специалист
Медсестра специалиста
Заведующий отделением
поликлиники
4.3.
Формирование врачебных назначений
Профильный специалист
лекарственных средств и/или процедур и Заведующий отделением
манипуляций
поликлиники
4.4.
Ведение первичной учетной
документации на уровне профильного
специалиста в соответствии с
действующими нормативными
правовыми актами РК
Профильный специалист
Медсестра
Заведующий отделением
поликлиники
4.5.
Ведение учета листов временной
нетрудоспособности
Профильный специалист
Заведующий отделением
поликлиники
4.6.
Формирование аналитических форм на
уровне профильного специалиста, а
также статистических таблиц в
соответствии с действующими
нормативными правовыми актами РК
Профильный специалист
Заведующий отделением
поликлиники
Главный врач
Медицинский статистик
поликлиники
5.
Модуль «Заведующий отделением
поликлиники»
5.1.
Подтверждение или отклонение
направлений на отдельные виды услуг с
использованием ЭЦП
Заведующий отделением
поликлиники
5.2.
Ведение первичной учетной
документации на уровне заведующего
отделением в соответствии с
действующими нормативными
правовыми актами РК
Заведующий отделением
поликлиники
5.3.
Формирование аналитических форм на
Заведующий отделением
уровне заведующего отделением, а также поликлиники
Раздел VI. Технические требования
384
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
Медицинский статистик
поликлиники
5.4.
Согласование листа временной
нетрудоспособности, ведение записей
ВКК
Заведующий отделением
поликлиники
6.
Модуль «Медицинская статистика
поликлиники»
6.1.
Мониторинг ведения первичной учетной Медицинский статистик
документации в Организации
поликлиники
Заведующий отделением
поликлиники
Главный врач
6.2.
Формирование аналитических форм на
уровне специалиста по медицинской
статистике, а также статистических
таблиц в соответствии с действующими
нормативными правовыми актами РК
7.
Модуль «Приемный покой»
7.1.
Регистрация поступления пациентов
Врач приемного покоя
Медсестра приемного покоя
Заведующий отделением
стационара
7.2.
Ведение ЭМЗ пациента
Врач приемного покоя
Медсестра приемного покоя
Заведующий отделением
стационара
7.3.
Уточнение услуг, выполненных до
госпитализации
Врач приемного покоя
Медсестра приемного покоя
Заведующий отделением
стационара
7.4.
Ведение первичной учетной
документации таблиц на уровне
приемного покоя в соответствии с
действующими нормативными
правовыми актами РК
Врач приемного покоя
Медсестра приемного покоя
Заведующий отделением
стационара
Медицинский статистик стационара
7.5.
Формирование аналитических форм на
Врач приемного покоя
Медицинский статистик
поликлиники
Заведующий отделением
поликлиники
Главный врач
Раздел VI. Технические требования
уровне приемного покоя, а также
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
385
Медсестра приемного покоя
Заведующий отделением
стационара
Медицинский статистик стационара
7.6.
Взаимодействие с ИС МЗСР РК
8.
Модуль «Врач стационара»
8.1.
Ведение ЭМЗ пациента
8.2.
Ведение направлений на
Врач стационара
консультативно-диагностические услуги Заведующий отделением
стационара
8.3.
Постановка диагноза
8.4.
Формирование врачебных назначений
Врач стационара
лекарственных средств и/или процедур и Заведующий отделением
манипуляций
стационара
8.5.
Выписка пациента
Врач стационара
Заведующий отделением
стационара
8.6.
Формирование аналитических форм на
уровне врача
Врач стационара
Заведующий отделением
стационара
Медицинский статистик стационара
8.7.
Ведение первичной учетной
документации на уровне врача
стационара
Врач стационара
Заведующий отделением
стационара
Медицинский статистик стационара
9.
Модуль «Медсестра стационара»
9.1.
Ведение ЭМЗ пациента
Медсестра стационара
9.2.
Отметка о выполнении назначений и
лечения
Медсестра стационара
Врач стационара
Заведующий отделением
стационара
Врач стационара
Заведующий отделением
стационара
Раздел VI. Технические требования
386
9.3.
Мониторинг состояния больного
Медсестра стационара
9.4.
Ведение первичной учетной
документации на уровне медицинской
сестры
Медсестра стационара
9.5.
Формирование и аналитических форм на Медсестра стационара
уровне медицинской сестры, а также
Медицинский статистик стационара
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
10.
Модуль «Питание»
10.1.
Формирование ежедневного меню
10.2.
Калькулятор ежедневного, ежемесячного Специалист пищеблока
расхода продуктов на меню
10.3.
Расчет пищевой ценности блюд в
рационе
Специалист пищеблока
10.4.
Формирование справочника основных
пищевых продуктов
Специалист пищеблока
10.5.
Управление диетой пациентов
Специалист пищеблока
10.6.
Формирование аналитических форм по
питанию
Специалист пищеблока
Медицинский статистик стационара
11.
Модуль «Дневной стационар»
11.1.
Ведение ЭМЗ пациента
11.2.
Создание направлений на
Врач стационара
консультативно-диагностические услуги Профильный специалист
Врач стационара
Заведующий отделением
стационара
Медсестра стационара
Специалист пищеблока
Врач стационара
Медсестра стационара
Профильный специалист
Медсестра специалиста
Заведующий отделением
поликлиники
Заведующий отделением
стационара
Раздел VI. Технические требования
387
Заведующий отделением
поликлиники
Заведующий отделением
стационара
11.3.
Регистрация врачебных назначений и их Врач стационара
выполнения
Медсестра стационара
Профильный специалист
Медсестра специалиста
Заведующий отделением
поликлиники
Заведующий отделением
стационара
11.4.
Ведение первичной учетной
документации на уровне дневного
стационара в соответствии с
действующими нормативными
правовыми актами РК
Врач стационара
Медсестра стационара
Профильный специалист
Медсестра специалиста
Заведующий отделением
поликлиники
Заведующий отделением
стационара
11.5.
Формирование аналитических форм на
уровне дневного стационара, а также
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
Врач стационара
Медсестра стационара
Профильный специалист
Медсестра специалиста
Заведующий отделением
поликлиники
Заведующий отделением
стационара
11.6.
Взаимодействие в ИС МЗСР РК
12.
Модуль «Заведующий отделением
стационара»
12.1.
Подтверждение или отклонение
направлений на отдельные виды услуг с
использованием ЭЦП
Заведующий отделением
стационара
12.2.
Ведение первичной учетной
документации на уровне заведующего
отделением в соответствии с
действующими нормативными
правовыми актами РК
Заведующий отделением
стационара
Раздел VI. Технические требования
388
12.3.
Формирование и аналитических форм на Заведующий отделением
уровне заведующего отделением, а также стационара
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
12.4.
Согласование больничного листа,
ведение записей консилиума
13.
Модуль «Главный врач»
13.1.
Формирование и аналитических форм на Главный врач
уровне главного врача, а также
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
14.
Модуль «Медицинская статистика
стационара»
14.1.
Ведение коечного фонда
Медицинский статистик стационара
14.2.
Формирование аналитических форм на
уровне кабинета медицинской
статистики, а также статистических
таблиц в соответствии с действующими
нормативными правовыми актами РК
Главный врач
Заведующий отделением
стационара
Медицинский статистик стационара
15.
Модуль «Процедуры и манипуляции»
15.1.
Ведение ЭМЗ пациента
Врач стационара
Медсестра стационара
Заведующий отделением
стационара
15.2.
Ведение первичной учетной
документации по оказанным процедурам
и манипуляциям в соответствии с
действующими нормативными
правовыми актами РК
Врач стационара
Медсестра стационара
Заведующий отделением
стационара
15.3.
Формирование аналитических форм по
оказанным процедурам и манипуляциям,
а также статистических таблиц в
соответствии с действующими
нормативными правовыми актами РК
Врач стационара
Медсестра стационара
Заведующий отделением
стационара
Медицинский статистик стационара
Заведующий отделением
стационара
Раздел VI. Технические требования
389
16.
Модуль «Администратор»
16.1.
Управление базой данных
Администратор
16.2.
Создание групп пользователей и
отдельных пользователей Системы
Администратор
16.3.
Управление типами аутентификации
(парольная, ЭЦП)
Администратор
16.4.
Ведение системных журналов
Администратор
16.5.
Настройка шаблонов медицинской
документации
Администратор
16.6.
Настройка пользовательского
интерфейса
Администратор
16.7.
Настройка доступа пользователей
Администратор
16.8.
Настройка подключения внешних
программ
Администратор
16.9.
Управление справочниками
Администратор
16.10. Создание, редактирование отчетных
форм при помощи мастера отчетных
форм
Администратор
17.
Модуль «Лабораторная
информационная система»
17.1.
Регистрация поступившего материала с
возможностью отбраковки
17.2.
Штрих-кодирование материала (создание Лаборант
штрих-кодов, идентификация по штрих- Специалист лаборатории
коду)
Врач-лаборант
17.3.
Формирование рабочих листов для
лабораторных анализаторов и
исполнителей
17.4.
Взаимодействие с лабораторным
оборудованием (экспорт направлений на
исследование, импорт результатов
Лаборант
Специалист лаборатории
Врач-лаборант
Лаборант
Специалист лаборатории
Врач-лаборант
Раздел VI. Технические требования
390
исследований)
17.5.
Ручной ввод результатов лабораторных
исследований
Лаборант
Специалист лаборатории
Врач-лаборант
17.6.
Подтверждение действительности
Специалист лаборатории
результатов лабораторных исследований Врач-лаборант
уполномоченным сотрудником
лаборатории
17.7.
Контроль качества лабораторных
исследований (внутрилабораторный,
межлабораторный, внешний)
17.8.
Возможность вывода на печать
Лаборант
результатов на основании утвержденной Специалист лаборатории
действующими нормативными
Врач-лаборант
правовыми актами РК первичной
учетной документации
17.9.
Введение референсных значений по
Специалист лаборатории
лаборатории как для всех пациентов, так Врач-лаборант
и по половозрастным группам
Специалист лаборатории
Врач-лаборант
17.10. Ведение первичной учетной
документации на уровне лаборатории в
соответствии с действующими
нормативными правовыми актами РК
Лаборант
Специалист лаборатории
Врач-лаборант
17.11. Формирование и аналитических форм на
уровне лаборатории, а также
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
Лаборант
Специалист лаборатории
Врач-лаборант
Медицинский статистик стационара
17.12. Возможность интеграции Системы с
самостоятельными Лабораторными
информационными системами
17.13. Передача информации о выполненных
исследованиях в ЭМЗ и ЭПЗ
18.
Модуль «PACS» (Picture Archiving
and Communication System)
18.1.
Обмен данными с медоборудованием
Раздел VI. Технические требования
391
18.2.
Взаимодействие с другими модулями и
системами на основе правил IHE
профилей
18.3.
Импорт/экспорт изображений
18.4.
Работа с изображениями
18.5.
Ведение архива изображений
19.
Модуль «Диагностические
исследования»
19.1.
Просмотр записанных по графику
пациентов
Врач диагностического отделения
Медсестра специалиста
Заведующий отделением
стационара
19.2.
Ввод результатов исследований на
основе шаблонов
Врач диагностического отделения
Медсестра специалиста
Заведующий отделением
стационара
19.3.
Ведение первичной учетной
документации по диагностическим
исследованиям в соответствии с
действующими нормативными
правовыми актами РК
Врач диагностического отделения
Медсестра специалиста
Заведующий отделением
стационара
19.4.
Формирование аналитических форм по
диагностическим исследованиям, а также
статистических таблиц в соответствии с
действующими нормативными
правовыми актами РК
Врач диагностического отделения
Медсестра специалиста
Заведующий отделением
стационара
Медицинский статистик стационара
19.5.
Передача информации о выполненных
исследованиях в ЭМЗ и ЭПЗ
20.
Модуль «Аптека»
Участковый врач
Профильный специалист
Заведующий отделением
поликлиники
Врач стационара
Заведующий отделением
стационара
Раздел VI. Технические требования
392
20.1.
Ведение учета медикаментов на разных
уровнях: поста, кабинета, отделения,
аптечного склада (одного или
нескольких), медицинской организации
Фармацевт
Провизор
Клинический фармаколог
20.2.
Автоматическое списание
лекарственных средств при выполнении
назначения
20.3.
Возможность отслеживания сроков
годности ЛС и ИМН
20.4.
Возможность формирования перечня
Фармацевт
лекарственных средств (изделия
Провизор
медицинского назначения) необходимых Клинический фармаколог
для закупа в организациях
20.5.
Формирование требований в аптеку на
получение лекарственных средств
(автоматические срочные требования
при наличии в листе назначений и
отсутствии в отделении, при снижении
запаса ниже установленного
критического минимума)
Медсестра специалиста
Медсестра участкового врача
Медсестра стационара
Фармацевт
Провизор
Клинический фармаколог
20.6.
Получение сведений о наличии
лекарственного препарата в отделениях
МО
Медсестра специалиста
Медсестра участкового врача
Медсестра стационара
Фармацевт
Провизор
Клинический фармаколог
20.7.
Ведение формуляра лекарственных
средств медицинской организации
Фармацевт
Провизор
Клинический фармаколог
20.8.
Регистрация побочного действия (ПД)
лекарственного средства в порядке
утвержденном нормативно-правовыми
документами
Участковый врач
Профильный специалист
Заведующий отделением
поликлиники
Врач стационара
Заведующий отделением
стационара
Врач диагностического отделения
20.9.
Мониторинг назначений лекарственных
Клинический фармаколог
Фармацевт
Провизор
Клинический фармаколог
Раздел VI. Технические требования
393
средств
20.10. Установка максимальных дозировок для Клинический фармаколог
контроля назначений
20.11. Регистрация и оформление
приходных/расходных документов
отделений и аптеки в соответствии с
нормативно-правовыми акта
Медсестра участкового врача
Медсестра специалиста
Медсестра стационара
Участковый врач
Профильный специалист
Заведующий отделением
поликлиники
Врач стационара
Заведующий отделением
стационара
Врач диагностического отделения
20.12. Ведение первичной учетной
документации на уровне аптеки в
соответствии с действующими
нормативными правовыми актами РК
Фармацевт
Провизор
Клинический фармаколог
20.13. Формирование аналитических форм на
уровне аптеки, а также статистических
таблиц в соответствии с действующими
нормативными правовыми актами РК
Фармацевт
Провизор
Клинический фармаколог
Медицинский статистик стационара
21.
Модуль «Кадры»
21.1.
Связь с национальными индексами
Специалист отдела кадров
21.2.
Ведение организационной структуры
медучреждения
Специалист отдела кадров
21.3.
Ведение учетной карточки врача
(работника здравоохранения)
Специалист отдела кадров
21.4.
Ведение режима работы работников
Специалист отдела кадров
21.5.
Ведение справочника услуг
Специалист отдела кадров
21.6.
Связь с информационной системой
бухгалтерского учета
Специалист отдела кадров
Раздел VI. Технические требования
394
Приложение 2
Примерный состав и количество модулей Системы для Организаций
Усть-Каменогорская городская больница №1
Модуль
Количество АРМ, использующих
функционал модулей
Модуль «Регистратура»
Модуль «Участковый врач»
Модуль «Ведение профилактических
осмотров»
Модуль «Профильный специалист»
Модуль «Заведующий отделением
поликлиники»
Модуль «Медицинская статистика
поликлиники»
Модуль «Приемный покой»
8
Модуль «Врач стационара»
72
Модуль «Медсестра стационара»
42
Модуль «Питание»
5
Модуль «Дневной стационар»
8
Модуль «Заведующий отделением
стационара»
25
Модуль «Главный врач»
6
Модуль «Медицинская статистика
стационара»
10
Модуль «Процедуры и манипуляции»
25
Модуль «Администратор»
5
Модуль «Лабораторная информационная
система»
17
Модуль «PACS» (Picture Archiving
8
Раздел VI. Технические требования
395
and Communication System)
Модуль «Диагностические исследования»
17
Модуль «Аптека»
5
Модуль «Кадры»
5
ИТОГО
258
Городская клиническая больница №4 г. Алматы
Модуль
Количество АРМ
Модуль «Регистратура»
Модуль «Участковый врач»
Модуль «Ведение профилактических
осмотров»
Модуль «Профильный специалист»
Модуль «Заведующий отделением
поликлиники»
Модуль «Медицинская статистика
поликлиники»
Модуль «Приемный покой»
15
Модуль «Врач стационара»
31
Модуль «Медсестра стационара»
12
Модуль «Питание»
2
Модуль «Дневной стационар»
3
Модуль «Заведующий отделением
стационара»
13
Модуль «Главный врач»
7
Модуль «Медицинская статистика
стационара»
6
Модуль «Процедуры и манипуляции»
13
Модуль «Администратор»
2
Раздел VI. Технические требования
396
Модуль «Лабораторная информационная
система»
5
Модуль «PACS» (Picture Archiving
and Communication System)
4
Модуль «Диагностические исследования»
4
Модуль «Аптека»
2
Модуль «Кадры»
4
ИТОГО
123
Центр матери и ребенка г. Усть-Каменогорск
Модуль
Количество АРМ
Модуль «Регистратура»
15
Модуль «Участковый врач»
11
Модуль «Ведение профилактических
осмотров»
32
Модуль «Профильный специалист»
32
Модуль «Заведующий отделением
поликлиники»
5
Модуль «Медицинская статистика
поликлиники»
8
Модуль «Приемный покой»
34
Модуль «Врач стационара»
75
Модуль «Медсестра стационара»
48
Модуль «Питание»
8
Модуль «Дневной стационар»
13
Модуль «Заведующий отделением
стационара»
22
Модуль «Главный врач»
1
Модуль «Медицинская статистика
12
Раздел VI. Технические требования
397
стационара»
Модуль «Процедуры и манипуляции»
26
Модуль «Администратор»
4
Модуль «Лабораторная информационная
система»
18
Модуль «PACS» (Picture Archiving
and Communication System)
11
Модуль «Диагностические исследования»
16
Модуль «Аптека»
9
Модуль «Кадры»
5
ИТОГО
405
Городская поликлиника №11 г.Алматы
Модуль
Количество АРМ
Модуль «Регистратура»
10
Модуль «Участковый врач»
31
Модуль «Ведение профилактических
осмотров»
6
Модуль «Профильный специалист»
37
Модуль «Заведующий отделением
поликлиники»
13
Модуль «Медицинская статистика
поликлиники»
11
Модуль «Приемный покой»
-
Модуль «Врач стационара»
-
Модуль «Медсестра стационара»
-
Модуль «Питание»
-
Модуль «Дневной стационар»
3
Модуль «Заведующий отделением
Раздел VI. Технические требования
398
стационара»
Модуль «Главный врач»
9
Модуль «Медицинская статистика
стационара»
-
Модуль «Процедуры и манипуляции»
6
Модуль «Администратор»
1
Модуль «Лабораторная информационная
система»
10
Модуль «PACS» (Picture Archiving
and Communication System)
Модуль «Диагностические исследования»
5
Модуль «Аптека»
1
Модуль «Кадры»
2
ИТОГО
145
Региональный диагностический центр г.Алматы
Модуль
Модуль «Регистратура»
Количество АРМ
9
Модуль «Участковый врач»
Модуль «Ведение профилактических
осмотров»
Модуль «Профильный специалист»
32
Модуль «Заведующий отделением
поликлиники»
10
Модуль «Медицинская статистика
поликлиники»
8
Модуль «Приемный покой»
1
Модуль «Врач стационара»
6
Модуль «Медсестра стационара»
3
Раздел VI. Технические требования
399
Модуль «Питание»
1
Модуль «Дневной стационар»
7
Модуль «Заведующий отделением
стационара»
1
Модуль «Главный врач»
4
Модуль «Медицинская статистика
стационара»
1
Модуль «Процедуры и манипуляции»
1
Модуль «Администратор»
2
Модуль «Лабораторная информационная
система»
7
Модуль «PACS» (Picture Archiving
and Communication System)
6
Модуль «Диагностические исследования»
37
Модуль «Аптека»
1
Модуль «Кадры»
2
ИТОГО
139
Поликлиника №1 города Костанай
Модуль
Количество АРМ
Модуль «Регистратура»
14
Модуль «Участковый врач»
34
Модуль «Ведение профилактических
осмотров»
7
Модуль «Профильный специалист»
17
Модуль «Заведующий отделением
поликлиники»
8
Модуль «Медицинская статистика
поликлиники»
11
Раздел VI. Технические требования
400
Модуль «Приемный покой»
Модуль «Врач стационара»
Модуль «Медсестра стационара»
Модуль «Питание»
Модуль «Дневной стационар»
7
Модуль «Заведующий отделением
стационара»
Модуль «Главный врач»
3
Модуль «Медицинская статистика
стационара»
Модуль «Процедуры и манипуляции»
7
Модуль «Администратор»
3
Модуль «Лабораторная информационная
система»
15
Модуль «PACS» (Picture Archiving
and Communication System)
7
Модуль «Диагностические исследования»
27
Модуль «Аптека»
3
Модуль «Кадры»
2
ИТОГО
165
Центральная районная больница Жуалынского района Жамбыльская область
Модуль
Модуль «Регистратура»
Количество АРМ
4
Модуль «Участковый врач»
24
Модуль «Ведение профилактических
осмотров»
49
Раздел VI. Технические требования
401
Модуль «Профильный специалист»
25
Модуль «Заведующий отделением
поликлиники»
2
Модуль «Медицинская статистика
поликлиники»
9
Модуль «Приемный покой»
2
Модуль «Врач стационара»
13
Модуль «Медсестра стационара»
13
Модуль «Питание»
1
Модуль «Дневной стационар»
2
Модуль «Заведующий отделением
стационара»
8
Модуль «Главный врач»
1
Модуль «Медицинская статистика
стационара»
3
Модуль «Процедуры и манипуляции»
9
Модуль «Администратор»
5
Модуль «Лабораторная информационная
система»
3
Модуль «PACS» (Picture Archiving
and Communication System)
1
Модуль «Диагностические исследования»
7
Модуль «Аптека»
2
Модуль «Кадры»
2
ИТОГО
185
Городская поликлиника №7 города Астаны
Модуль
Модуль «Регистратура»
Количество АРМ
6
Раздел VI. Технические требования
402
Модуль «Участковый врач»
26
Модуль «Ведение профилактических
осмотров»
3
Модуль «Профильный специалист»
40
Модуль «Заведующий отделением
поликлиники»
12
Модуль «Медицинская статистика
поликлиники»
8
Модуль «Приемный покой»
-
Модуль «Врач стационара»
Модуль «Медсестра стационара»
Модуль «Питание»
Модуль «Дневной стационар»
3
Модуль «Заведующий отделением
стационара»
Модуль «Главный врач»
1
Модуль «Медицинская статистика
стационара»
Модуль «Процедуры и манипуляции»
4
Модуль «Администратор»
2
Модуль «Лабораторная информационная
система»
8
Модуль «PACS» (Picture Archiving
and Communication System)
3
Модуль «Диагностические исследования»
16
Модуль «Аптека»
2
Модуль «Кадры»
3
ИТОГО
137
Раздел VI. Технические требования
403
Городская больница №1 города Астаны
Модуль
Количество АРМ
Модуль «Регистратура»
Модуль «Участковый врач»
Модуль «Ведение профилактических
осмотров»
Модуль «Профильный специалист»
Модуль «Заведующий отделением
поликлиники»
Модуль «Медицинская статистика
поликлиники»
Модуль «Приемный покой»
20
Модуль «Врач стационара»
65
Модуль «Медсестра стационара»
22
Модуль «Питание»
Модуль «Дневной стационар»
Модуль «Заведующий отделением
стационара»
22
Модуль «Главный врач»
8
Модуль «Медицинская статистика
стационара»
6
Модуль «Процедуры и манипуляции»
Модуль «Администратор»
5
Модуль «Лабораторная информационная
система»
4
Модуль «PACS» (Picture Archiving
and Communication System)
14
Модуль «Диагностические исследования»
10
Раздел VI. Технические требования
404
Модуль «Аптека»
4
Модуль «Кадры»
5
ИТОГО
185
Раздел VI. Технические требования
405
Приложение 3
Серверное оборудование и программные продукты для организаций здравоохранения
Сервер
M001
M002
M003
M004
M005
M006
M007
M008
M009
M010
M011
M012
M013
M014
M015
M016
Количествосерверов: 1
Исполнение на единицу сервера:rack, не более 2U
Количество процессоров на единицу сервера, разрядность: не менее 2, не менее
8-ми ядерного процессора 2,6 GHz.
Установленная оперативная память на единицу сервера: не менее 64 GB
Максимальный объем памяти на единицу сервера: не менее 768 GB, не менее 24
слотов памяти
Тип оперативной памяти на единицу сервера:PC3-12800RDIMMDDR3-16000
МГц, ECC-коррекция многобитовых ошибок, режим lock-step. Поддержка модулей
UDIMM.
RAID контроллер на единицу сервера:SAS, не менее 8 портов, 512MB кэш
памяти, поддержка уровней RAID 0, 1+0; отказоустойчивый ROM, online миграция
между уровнями RAID, увеличение емкости без остановки работы, online
увеличение размера существующих логических томов. Поддержкадо 2ГБ флэшкэшпамяти.
Дисковая подсистема на единицу сервера: не менее 2 х 300GB 10KSAS 2.5 “.
Тип поддерживаемых дисков:SAS, SATA, SSDSAS, SSDSATA.
Максимальное количество дисков: Не менее 25-ти дисков формата 2.5" (SFF) или
не менее 12-ти дисков формата 3.5" (LFF).
FC адаптер на единицу сервера:не менее 2-х 8Gbit SingleportFibre Channel Adapter
Максимальное количество слотов расширения на единицу сервера: Не менее 6
PCI-Express
Сетевые интерфейсы на единицу сервера: не менее 4 встроенных портов
1GbEthernet
Управление: Средства для дистанционного управления и мониторинга сервера:
независимая от состояния ОС удаленная текстовая и видео консоль, виртуальное
медиа, поддержка скриптов для автоматизации обновлений ПО, управление
электропитанием, командная строка и web-интерфейс, выделенный порт 10/100,
поддержка SSH, SSL для защищенного соединения с сервером, поддержка
DHCP/DNS/WINS
Возможность проактивного мониторинга оперативной памяти и жестких дисков.
Возможность удаленного управления с мобильных устройств на базе ОС iOS,
Android.
Возможность удаленного мониторинга без предустановленных агентов под ОС.
Видеоподсистема на единицу сервера: интегрированная
Параметры электропитания на единицу сервера: не менее 2 шт 750Ватт, горячей
замены не менее чем N+1. Поддержка блоков питания с возможностью
подключения
к
цепям
постоянного
или
переменного
тока.
Раздел VI. Технические требования
406
Поддержкаблоковпитания не менеечем 1200 Ватт.
M017
M019
Интерфейсы:неменее 7шт USB, 1 шт SD, 1 шт Serial, 2 шт Video.
Лицензионное программное обеспечение: операционная система
MicrosoftWindowsServerStandard 2012 R2, лицензии на ПО виртуализации для 2-х
процессоров. Программное обеспечение должно быть установлено,
зарегистрировано и активизировано
Требования к комплектности поставки: комплект поставки включает полный
комплект драйверов для установленных устройств, компакт-диски с
дистрибутивами к операционной системе MicrosoftWindowsServerStandard 2012. В
состав комплекта должны быть включены все необходимые кабели подвода
электрического питания.
LAN коммутатор:
M020
Количество: неменее 1 шт.
M021
M029
Количество портов: не менее 24 шт.
Скорость портов: не менее 10/100/1000 EthernetGbit/s.
Память и процессор: Не менее 1 ГБ SDRAM, размер пакетного буфера: 4 МБ,
флэш-память 512 МБ
Пропускная способность: Не менее 155 млн. пакетов в секунду.
Производительность: неменее 208Gbps
Количество MAC-адресов: Не менее 32000
Размер таблицы маршрутизации: Не менее 16000 строк
Функции: Layer 2 и Layer 3.
Источник бесперебойного питания (ИБП):
Количество: 1
M030
Исполнение: Для установки в серверный шкаф.
M031
Максимальная выходная мощность на единицу ИБП: не менее 3000W/3300VA
M032
Номинальное выходное напряжение на единицу ИБП: не менее 230V+/- 10
M018
M022
M023
M024
M025
M026
M027
M028
M033
Эффективность: неменее 95%.
M034
Выходная частота (синхронизированная с электросетью): 50/60 Гц -10%, + 6%
M035
Время работы при нагрузке 50%: Не менее 12 мин.
Система хранения данных для сервера
M036
M037
M038
Исполнение: Для установки в серверный шкаф.
Количество и тип установленных дисков: не менее 8 дисков 300GB 15KrpmSAS
6 Гб/с
Максимальный объем дисковой подсистемы: Не менее 192 TB
Раздел VI. Технические требования
M039
M040
M041
M042
407
Контроллер для подключения дисковой стойки к серверу: Не менее 2-х
активных контроллеров, поддержка уровней RAID 0, 1, 3, 5, 6, 10, 50; поддержка
расширения до не менее чем 48-ти жестких дисков 3.5”, 99 жестких досков 2.5”.
Кэш память: Размер кэш-памяти каждого контроллера – не менее 4ГБ. Кэш-память
должна использоваться только для хранения данных и управляющей информации,
кэш-память не должна использоваться для задач операционной системы массива.
Кэш-память должна зеркалироваться между контроллерами по внутренним каналам
(использование каналов доступа к дискам для зеркалирования кэш-памяти не
допустимо). Неограниченная по времени поддержка сохранности содержимого
кэш-памяти – на случай отключения электропитания (использование дисковой
памяти
для
хранения
кэш-памяти
не
допустимо).
Кэшмассивадолженподдерживатьрежимкоррекцииошибок ECC.
Поддерживаемые диски: двух портовые диски: 146/300/450/600/900/1000/1200 GB
2,5” SAS, 1/2/3/4 TB 3,5” SAS.
Интерфейс контроллера:FC, 8 Гб/с. Не менее 2 портов.
M043
Число поддерживаемых хостов: Поддержка одновременное подключение к 64-м
серверам
M044
Поддержка логических дисков: Одновременно до не менее 512 логических
дисков; Возможность создания логических дисков размером до не менее 128ТБ.
M045
Программное Обеспечение:
Массив должен поддерживать на аппаратном уровне создание локальных копий
томов двух типов – snapshot (мгновенная копия) и snapclone (полная копия).
Поддержка не менее 512 «моментальных снимков» данных. В состав входит
лицензия на 64 snapshots.
Массив должен поддерживать на аппаратном уровне репликацию данных между
двумя однотипными массивами в асинхронном режиме.
Массив должен поддерживать репликацию “many-to-one”: до 4 систем хранения из
удаленных офисов на одну.
ПО управления дискового массива должно поддерживать интеграцию с
VMwarevCenter, администратор дискового массива должен иметь возможность
создавать/расширять/удалять хранилища массива и создавать виртуальные машины
из vCenter.
Должна быть предусмотрена возможность отслеживать текущее состояние и
производительность массива из vCenter.
Возможности массива: Для снижения энергопотребления дисковый массив
должен поддерживать возможность автоматической остановки или замедления
вращения дисков (если в течение некоторого времени к дискам не происходит
обращений).
Поддержка резервных дисков (sparedisks), как глобальных, так и выделенных для
определенной RAID-группы.
Дисковый массив должен поддерживать подключение серверов, как минимум, по
двум путям для дублирования каналов доступа (pathfailover), также должна
поддерживаться балансировка нагрузки между различными путями доступа
(loadbalancing).
M046
Раздел VI. Технические требования
M047
M048
408
Необходимое ПО для дублирования и балансировки каналов должно быть
включено в комплект поставки.
Массив должен поддерживать обновление с моделей предыдущих поколений,
путем замены контроллеров, при этом диски и полки от моделей предыдущих
поколений должны в полной мере поддерживаться новыми контроллерами;
Отказоустойчивость:Дисковый массив должен иметь полностью
отказоустойчивую архитектуру, в массиве должно быть предусмотрено полное
дублирование всех активных компонент и путей доступа. Как минимум, должны
дублироваться контроллеры, блоки ввода-вывода, вентиляторы и блоки питания,
каналы соединения контроллерной полки с дисковыми полками расширения.
Вентиляторы и блоки питания: Двойные с возможностью горячей замены.
Дисковый массив должен поддерживать подключение к сетям переменного тока и к
сетям постоянного тока.
Шкафсерверный
M050
Шкаф серверный должен быть напольного исполнения для монтажа
оборудования 19''
Высота: неболее 21U
M051
Размеры: не более 600х1000 мм.
M052
Конфигурация:
 спереди:
o дверь одностворчатая- стекло в стальной раме,
o Поворотная ручка с профилем стандарта DIN,
o универсальный ключ типа EK 333,
o многоточечный механизм запирания, открытие на 180 градусов
 сзади:
o дверь одностворчатая- сплошной стальной лист;
o Поворотная ручка с профилем стандарта DIN,
o универсальный ключ типа EK 333,
o многоточечный механизм запирания
o 2 боковые стенки, каркас из стали 2мм,
o универсальный ключ
o без крыши, днище - типа Z,
o Должен быть подготовлен для монтажа кондиционера, степень
защиты не ниже IP54
o 19' вертикальные направляющие: не более 2 пары, А-типа
o должен комплектоваться комплектом для заземления,
o не менее 28 комплектов крепежа
o грузоподъемность: не менее 1500кг
 Днище:
o должно быть прямоугольное отверстия (не более 300x100 мм) для
ввода кабеля
o закрыты съемными стальными заглушками
Рамки для отделения холодного воздуха: наличие рамки для отделения холодной
зоны перед 19" направляющими, для шкафов с направляющими A-типа,
M049
M053
Раздел VI. Технические требования
M054
M055
409
изменяющаяся глубина холодной зоны, для шкафов высотой не менее 21U,
шириной не менее 600мм
Дефлектора потока воздуха: наличие дефлектора потока воздуха, для
холодильного агрегата AC, установленного на шкаф шириной не менее 600мм;
совместим с разделительной рамой 150мм
Комплектность: шкаф коммутационный должен поставлять в комплекте с
набором систем не менее чем:
 Система охлаждения
 Локальная система пожаротушения
 Система мониторинга
 Система контроля доступа
Требования к системеохлаждения
M057
Тип: Шкафной (монтаж на крыше коммутационного шкафа), непосредственное
охлаждение, без внешнего блока
Охлаждающая способность: не менее 5 200 Вт
M058
Макс. рабочий ток: не более 4,6
M059
Энергопотребление: неболее 2 540
M060
Расход воздуха в шкафу: не менее 1 720 литров
M061
Вентилятор: Радиальный
M062
Теплообменник: долженбыть
M056
Требования к Локальной система пожаротушения
M063
Локальная система пожаротушения должна включать в себя главное
устройство (MASTER), включая контрольную панель, не менее чем два
датчика и цилиндр с огнегасящим составом:
•
Датчики, расположенные внутри шкафа, должен обнаруживать
возгорание без задержек и на самом раннем этапе
•
Процедура тушения должна запускается немедленно после
обнаружения возгорания.
•
Процесс пожаротушения должен быть безвреден для оборудования.
•
Простота установки должна обеспечиваться простым подключение
систему к источнику питания шкафа.
•
Система должна быть рекомендована для использования в шкафах
уровня защиты IP30 и выше.
•
Благодаря возможности получения доступа к показаниям детекторов
и модульной структуре системы должна упрощать процедуру проверки и
обслуживания.
•
Главное устройство должно быть оснащено подробным легкочитаемым светодиодным индикаторным табло
•
Размеры устройства должны занимать не более 3U высоты 19" шкафа
•
Должна быть встроенная аккумуляторная батарея обеспечивающая
работоспособность системы при отключении электричества
Раздел VI. Технические требования
410
M064
Ширина устройства: не более 19"
M065
Высота устройства: не более 2,5U
M066
Глубина базовой части устройства: не более 382 мм
M067
M068
Максимальная глубина устройства (при выдвижении задней консоли с
датчиками) : не более 750 мм
Диапазон рабочих температур: от ‑ 5 °C до +50 °C
M069
Относительная влажность воздуха : не более 95 % без конденсации
M070
Рабочийрежим: постоянноефункционирование
M071
Входная мощность: не более 40ВА
M072
Степень защиты: не менее IP30
M073
Напряжение основного источника питания: не более 230 В ± 15 %
M074
Частота основного источника питания: не более 50 Гц
M075
M076
Максимальный ток, подаваемый основным источником питания: не более 1,25
A
Ток в режиме ожидания: не более 210 мА
M077
Потребление тока в режиме предварительной тревоги: не более 300 мА
M078
Потребление тока в режиме тревоги: не более 2 A
M079
Максимальное потребление тока выходами в режиме ожидания: не более 40
мА
Максимальное потребление тока выходами в режиме тревоги: не более 0,5 A
M080
M083
Максимальное выходное напряжение на терминал X32 (перезарядка
внутренней батареи) : не более 13,7 В
Максимальный ток из терминала X32 (перезарядка внутренней батареи) : не
более 200 мА
Резервный источник питания: 12В / 7,2Ач
M084
Максимальный объем шкафа (со степенью защиты - мин. IP30) :неболее 1,5 м3
M085
Максимальный объем шкафа (закрытый) : не более 3 м3
M081
M082
Требования к Системемониторинга
Контроллер
M086
интеллектуальных портов (Вход/Выход): не менее 8
M087
расширения на передней панели: не менее 4
M088
порт Modbus (RS-485): Да
M089
порт USB 2.0 для подключения GSM-модема, адаптера Bluetooth или Wi-Fi: Да
M090
Монтажная высота: не более 1U
Раздел VI. Технические требования
411
M091
Напряжение: не более 7 – 9 В пост. тока, 3 A
M092
Энергопотребление: не более 5,025 Вт, 0,67 A
M093
Разъем для карты памяти (SD): на передней панели
M094
Электропитание всех аксессуаров обеспечивается: контроллером
M095
Встроенный протокол TCP/IP и веб-сервер
M096
Наличие виртуальных датчиков для мониторинга электропитания, сторонних
устройств по сети Modbus или SNMP
Точность системного времени и даты обеспечивается встроенной
аккумуляторной батареей
M097
M098
Полнаяподдержка Modbus: Modbus Master/Slave, Modbus RTU, Modbus по TCP/IP
M099
Интеграция в систему управления сетью: Да
M0100
M0102
Датчик: 1-проводный датчик температуры и влажности (кабель - 30см, муфта RJ45)
Должно объединить все установленные системы мониторинга на 10 объектах в
единую систему
Лицензия: неболее 99 датчиков
M0103
Поддержка на обновление: не менее 5 лет
M0104
Визуализация: ПО должно поддерживать загрузку изображения/карты объекта и
расположения иконок датчиков/детекторов на карте.
Управление доступом: не менее полное управление учетными записями
отдельных пользователей и групп пользователей
Интеграция в системы управления сетью посредством: не менее SNMPv1 и
EncryptedSNMPv3.
Требования к системе контроля доступа в шкаф
M0101
M0105
M0106
Контролер
M0107
M0108
M0109
Контроль RDU модулей расширения для одного контроллера: не более 100
RDU
в последовательном подключении RDU на один порт расширения: не более 25
RDU
интеллектуальных порта для датчиков: не более 2х
Электронныйдвернойзамок
M0110
M0111
M0112
Электронный дверной замок: должен быть электронный дверной замок с
профильным полуцилиндром и встроенный картридером (EM&HIDProx формат
125kHz), с кабелем не менее 4.5 м
(Опционально) Расширитель для подключения: должна быть возможность
установки расширителя для подключения не менее чем 2 замка в один порт
Считыватель для программирования: USBDesktopCardReader (EM&HIDformat
125kHz ) для программирования карт;
Раздел VI. Технические требования
M0113
M0114
M0115
M0116
412
Карта доступа: HIDProxCards, 125kHz в количестве не менее 30 штук на комплект
оборудования
Требования к специалистам на данный тип оборудования: наличие у
потенциального поставщика не менее 2-х сертифицированных специалистов по
предлагаемому оборудованию для следующего оборудования: дискового массива,
серверного оборудования, активного сетевого оборудования.
Инсталляция: Инсталляция всего оборудования под ключ в серверном помещении
медецинских организациях сертифицированными специалистами.
Гарантия: не менее 3 лет круглосуточно, включая праздничные дни, время
реакции не более 4 часов круглосуточно на оборудование.
Характеристика планируемого серверного оборудования
Сервер
Количество серверов: 1
Исполнение на единицу сервера:rack, не более 2U
Количество процессоров на единицу сервера, разрядность: не менее 2, не менее 8ми ядерного процессора 2,6 GHz.
Установленная оперативная память на единицу сервера: не менее 64 GB
Максимальный объем памяти на единицу сервера: не менее 768 GB, не менее 24
слотов памяти
Тип оперативной памяти на единицу сервера:PC3-12800RDIMMDDR3-16000 МГц,
ECC-коррекция многобитовых ошибок, режим lock-step. Поддержка модулей UDIMM.
RAID контроллер на единицу сервера:SAS, не менее 8 портов, 512MB кэш памяти,
поддержка уровней RAID 0, 1+0; отказоустойчивый ROM, online миграция между
уровнями RAID, увеличение емкости без остановки работы, online увеличение размера
существующих логических томов. Поддержкадо 2ГБ флэш-кэшпамяти.
Дисковая подсистема на единицу сервера: не менее 2 х 300GB 10KSAS 2.5 “.
Тип поддерживаемых дисков:SAS, SATA, SSDSAS, SSDSATA.
Максимальное количество дисков: Не менее 25-ти дисков формата 2.5" (SFF) или не
менее 12-ти дисков формата 3.5" (LFF).
FC адаптер на единицу сервера:не менее 2-х 8Gbit SingleportFibre Channel Adapter
Максимальное количество слотов расширения на единицу сервера: Не менее 6
PCI-Express
Сетевые интерфейсы на единицу сервера: не менее 4 встроенных портов
1GbEthernet
Управление: Средства для дистанционного управления и мониторинга сервера:
независимая от состояния ОС удаленная текстовая и видео консоль, виртуальное
медиа, поддержка скриптов для автоматизации обновлений ПО, управление
электропитанием, командная строка и web-интерфейс, выделенный порт 10/100,
поддержка SSH, SSL для защищенного соединения с сервером, поддержка
DHCP/DNS/WINS
Возможность проактивного мониторинга оперативной памяти и жестких дисков.
Раздел VI. Технические требования
413
Возможность удаленного управления с мобильных устройств на базе ОС iOS, Android.
Возможность удаленного мониторинга без предустановленных агентов под ОС.
Видеоподсистема на единицу сервера: интегрированная
Параметры электропитания на единицу сервера: не менее 2 шт 750Ватт, горячей
замены не менее чем N+1. Поддержка блоков питания с возможностью подключения к
цепям постоянного или переменного тока. Поддержкаблоковпитания не менеечем 1200
Ватт.
Лицензионное программное обеспечение: операционная система
MicrosoftWindowsServerStandard 2012 R2, лицензии на ПО виртуализации для 2-х
процессоров. Программное обеспечение должно быть установлено, зарегистрировано
и активизировано
Требования к комплектности поставки: комплект поставки включает полный
комплект драйверов для установленных устройств, компакт-диски с дистрибутивами к
операционной системе MicrosoftWindowsServerStandard 2012. В состав комплекта
должны быть включены все необходимые кабели подвода электрического питания.
Система хранения данных для сервера
Исполнение: Для установки в серверный шкаф.
Количество и тип установленных дисков: не менее 8 дисков 300GB 15KrpmSAS 6
Гб/с
Максимальный объем дисковой подсистемы: Не менее 192 TB
Контроллер для подключения дисковой стойки к серверу: Не менее 2-х активных
контроллеров, поддержка уровней RAID 0, 1, 3, 5, 6, 10, 50; поддержка расширения до
не менее чем 48-ти жестких дисков 3.5”, 99 жестких досков 2.5”.
Кэш память: Размер кэш-памяти каждого контроллера – не менее 4ГБ. Кэш-память
должна использоваться только для хранения данных и управляющей информации,
кэш-память не должна использоваться для задач операционной системы массива. Кэшпамять должна зеркалироваться между контроллерами по внутренним каналам
(использование каналов доступа к дискам для зеркалирования кэш-памяти не
допустимо). Неограниченная по времени поддержка сохранности содержимого кэшпамяти – на случай отключения электропитания (использование дисковой памяти для
хранения
кэш-памяти
не
допустимо).
Кэшмассивадолженподдерживатьрежимкоррекцииошибок ECC.
Поддерживаемые диски: двух портовые диски: 146/300/450/600/900/1000/1200 GB
2,5” SAS, 1/2/3/4 TB 3,5” SAS.
Интерфейс контроллера:FC, 8 Гб/с. Не менее 2 портов.
Число поддерживаемых хостов: Поддержка одновременное подключение к 64-м
серверам
Поддержка логических дисков: Одновременно до не менее 512 логических дисков;
Возможность создания логических дисков размером до не менее 128ТБ.
Раздел VI. Технические требования
414
Технические требования (включая график
реализации) – Лот № 10
«Медицинская информационная система для учета
доноров, реципиентов и лиц, ожидающих
трансплантацию»
A. ОСНОВАНИЕ
0.1
Покупатель
0.1.1 Исполнительной организацией настоящего контракта является Министерство
здравоохранения и социального развития Республики Казахстан. Министерство
здравоохранения и социального развития Республики Казахстан является центральным
исполнительным органом Республики Казахстан, осуществляющим государственное
регулирование в области охраны здоровья граждан, медицинской и фармацевтической
науки,
медицинского
и
фармацевтического
образования,
санитарноэпидемиологического благополучия населения, обращения лекарственных средств,
контроля за качеством медицинских услуг. Министерство осуществляет свою
деятельность в соответствии с Конституцией и законами Республики Казахстан,
актами Президента, Правительства Республики Казахстан, иными нормативными
правовыми актами, а также Положением о Министерстве, утвержденным
Постановлением Правительства Республики Казахстан от 23 сентября 2014 года №
1005.
0.1.2 Заинтересованные стороны проекта, которые будут реализованы в результате
текущего тендера это:
 МЗСР РК (https://www.mzsr.gov.kz/), которое определяет стратегию
электронного здравоохранения, и обеспечит поставщика необходимыми
нормативными актами и соответствующими приказами для успешной
реализации контракта и корректировки регламентов в случае необходимости.
 Организации здравоохранения Республики Казахстан, которые будут
бенефициаром Контракта, и будут использовать результаты Контракта в
практической деятельности (далее – Организация).
Дополнительные детали по вовлечению заинтересованных сторон в
реализацию контракта предоставлены в следующих главах.
0.2
Цели Покупателя
0.2.1 Общая цель МЗСР РК в области электронного здравоохранения:
Раздел VI. Технические требования
415
Обеспечить компьютеризированную поддержку сбора актуальной,
точной и полной информации для обеспечения безопасной, справедливой,
высококачественной и устойчивой системы здравоохранения, ориентированной
на потребности пациентов. Это будет достигнуто путем предоставления в
медицинские учреждения и департаменты МЗСР РК высокопроизводительного
и безопасного доступа к полнофункциональным интероперабельным системам
электронного здравоохранения, основанным на безбумажной технологии с
использованием единой системы электронного паспорта здоровья. На
центральном уровне будет создан национальный репозиторий электронного
здравоохранения, содержащий: (I) ЭПЗ как центральный компонент,
интеграции данных из разрозненных ИС медицинских организаций, и (II)
хранилище высококачественной статистической, аналитической и финансовой
информации.
«Медицинская информационная система для учета доноров, реципиентов и лиц,
ожидающих трансплантацию» (далее - Система), приобретенная в рамках
настоящего контракта, внесет значительный вклад в достижение этого видения.
Система предназначена для автоматизации процессов формирования
электронного регистра доноров, пациентов, находящихся на листе ожидания и
реципиентов, автоматизации бизнес-процессов координационной службы по
трансплантации, автоматизации процессов подбора пары «донор-реципиент».
0.2.2
Основные цели электронного здравоохранения РК.
На основе анализа приоритетных потребностей системы здравоохранения РК,
намеченных основными направлениями Государственной программы
«Саламатты Казахстан на 2011-2015 годы», а также ключевых приоритетов,
перечисленных в «Стратегии Казахстан 2050», касающиеся здравоохранения,
для электронного здравоохранения устанавливаются следующие Основные
задачи:
1.
содействие процессу принятия клинических (медицинских)
решений;
2.
снижение количества медицинских ошибок;
3.
повышение доступности и совершенствование непрерывности
оказания медицинской помощи;
4.
повышение качества медицинских услуг;
5.
улучшение
качества
и
эффективности
принимаемых
политических, управленческих и финансовых решений;
6.
обеспечение условий для непрерывного профессионального
развития в сфере здравоохранения;
7.
повышение доступа населения к информации о своем здоровье и к
управлению вопросами их конфиденциальности;
8.
повышение рентабельности и эффективности инвестиций и
операционных расходов в здравоохранении.
0.2.3
Система, поставляемая в рамках данного
обеспечивать такие преимущества, как:
тендера,
будет
Раздел VI. Технические требования
416
 Эффективный сбор информации о тканях, донорах, реципиентах и лицах,
нуждающихся в трансплантации;
 Актуальность информации о доступных тканях и органах;
 Накопление статистической информации;
 Простой мониторинг текущего состояния реципиентов;
 Простой мониторинг текущего состояния, пациентов, нуждающихся в
трансплантации;
 Автоматизация процессов формирования регистра доноров, пациентов,
нуждающихся в трансплантации и реципиентов;
 Автоматизация бизнес-процессов
трансплантации,
координационной
службы
по
 Автоматизация процессов подбора пары «донор-реципиент».
0.2.4. Потенциальные бенефициары Системы.
Потенциальными прямыми бенефициарами Системы являются:
 Медицинские работники-врачи, медсестры, использующие Систему для
хранения и использования информации о пациентах при принятии
клинических решений, используя контекстную помощь в форме
клинических протоколов и т.д.
 Менеджеры здравоохранения, использующие информацию, собранную
из различных источников данных и различных объектов;
 Сотрудники МЗСР РК, использующие данные для принятия
политических решений и внесения изменений в нормативную базу на
основе доказательств, для корректного финансирования за оказанные
медицинские услуги;
 Внешние
информационные
системы,
использующие
сохраненные в приложениях электронного здравоохранения;
данные,
Следующие потенциальные косвенные бенефициары Системы:
 Все граждане Казахстана, обслуживаемые медицинскими работниками с
помощью Системы;
 Исследователи, использующие данные о лечебно-профилактическом
процессе, полученные с помощью Системы.
0.2.5.
Информационные системы Министерства
социального развития Республики Казахстан.
здравоохранения
К информационным системам Министерства здравоохранения и социального
развития Республики Казахстан относятся следующие системы:
и
Раздел VI. Технические требования
417
1.
Система «Бюро госпитализации»
2.
Система «Дополнительный компонент к тарифу ПМСП»
3.
Система «Лекарственное обеспечение»
4.
Система «Регистр беременных и женщин фертильного возраста»
5.
Система «Система управления качеством медицинских услуг»
6.
Система «Система управления медицинской техникой»
7.
Система «Система управления ресурсами»
8.
Система «Электронный регистр диспансерных больных»
9.
Система «Электронный регистр онкологических больных»
10.
Система «Электронный регистр стационарных больных»
11.
Система «Амбулаторно-поликлиническая помощь»
12.
Система «Регистр прикрепленного населения»
13.
Система «Учет больных с хронической почечной недостаточностью»
14.
Система «Регистр психических больных»
15.
Система «Регистр наркологических больных»
16.
Система управления лекарственным обеспечением
17.
АИС «Поликлиника»
18.
Система «Национальный регистр больных туберкулезом»
19.
Система «Национальный регистр «Сахарный диабет»»
20.
Платформа информатизации и интероперабельности здравоохранения
Взаимодействие с ИС МЗСР РК (вышеуказанными ИС в пунктах 1-19) будет
осуществляться
посредством
сервисов
Платформы
информатизации
и
интероперабельности здравоохранения.
0.3
Акронимы, используемые в этих технических требованиях
Термин
БД
Объяснение
База данных
ИИН
Индивидуальный идентификационный номер
ИКТ
Информационно-коммуникационные технологии
ИС
Информационная система
КЗГ
Клинико-затратная группа
ЛПО
Лечебно-профилактическая организация
МЗСР РК
Министерство здравоохранения и социального развития
Республики Казахстан
МКБ
Международная классификация болезней
НПА
Нормативно-правовые акты
ОРИТ
Отделение реанимации и интенсивной терапии
ПМСП
Первичная медико-санитарная помощь
Раздел VI. Технические требования
Термин
418
Объяснение
ПО
Программное обеспечение
РК
Республика Казахстан
Интероперабельность
Свойство или возможность различных систем работать
совместно
СОА
Сервис-ориентированная архитектура
СТП
Служба технической поддержки поставщиков
ФИО
Фамилия, имя, отчество
ЭМЗ
Электронная медицинская запись
ЭПЗ
Электронный паспорт здоровья
ЭЦП
Электронная цифровая подпись
ADO.NET
Технология, предоставляющая доступ к данным для
приложений, основанных на Microsoft .NET. Не является
развитием более ранней технологии ADO.
ASP
CPU
Активные серверные
страницы,
технология,(англ.
предложенная
Центральный
процессор
компьютера
Central
Microsoft 1996
Processing
Unit)году (англ. Active Server Page)
BAM CRUD
CSS
BP
BPM
DICOM
bps
BRMS
CDA
Мониторинг
бизнесчтения,
процессов
(англ.и Business
activity
Операции
создания,
обновления
удаления данных
monitoring)
(англ.
Create Read, Update, Delete operations)
CSS
Бизнес
(англ.
процесс
Cascading
(англ. Business
Style Sheets
Process)
— каскадные таблицы
стилей) — формальный язык описания внешнего вида
Управление бизнес процессами (англ. Business Process
документа, написанного с использованием языка разметки.
Management)
Отраслевой стандарт создания, хранения, передачи и
Бит в секунду (англ. Bits per second)
Информационная система, используемая для ведения,
поддержки и исполнения бизнес-правил компании
(англ. Business Rule Management System —
система
управления бизнес-правилами).
Архитектура клинического
Document Architecture)
документа
(англ.
Clinical
Раздел VI. Технические требования
419
визуализации медицинских изображений и документов
обследованных пациентов (англ. Digital Imaging and
Communication in Medicine)
DOM
DOM (англ. Document Object Model — «объектная модель
документа») — это не зависящий от платформы и языка
программный интерфейс, позволяющий программам и
скриптам получить доступ к содержимому HTML, XHTML
и XML-документов, а также изменять содержимое,
структуру и оформление таких документов.
ESB
Сервисная шина предприятия (англ. Enterprise Service Bus)
FHIR
Стандарт электронного обмена медицинской информацией
Стандарт FHIR – это новая спецификация от HL7,
основанная на новейших подходах в отрасли электронного
здравоохранения, но учитывающая весь накопленный опыт
(реальные потребности, успешные решения и типичные
трудности) определения и реализации стандартов HL7 v2,
HL7 v3, CDA. (англ. Fast Healthcare Interoperability
Resources)
GB
Гигабайт (англ. Gigabyte)
GUI
Пользовательский графический интерфейс (англ. Graphical
User Interface)
HC
Здравоохранение (англ. Healthcare)
Help Desk
Техническая поддержка или техподдержка, обобщающая
собой и охватывающая множество услуг, посредством
которых предприятия и организации обеспечивают помощь
пользователям технологичных продуктов и услуг.
HL7
Стандарт обмена, управления и интеграции электронной
медицинской информации. (англ. Health Level 7)
HTML
Язык гипертекстовой разметки (англ. Hypertext Markup
Language)
IaaS
Инфраструктура как услуга (англ. Infrastructure as a Service)
ICPC
Международный
классификатор,
оказания
первичной
помощи
Classification in Primary Care)
IDE
Интегрированная среда
Development Environment)
IHE
Интеграция предприятия, оказывающего медицинские
услуги. (англ. Integrating Healthcare Enterprise)
IP
применяемый
для
(англ.
International
разработки
(англ.
Интернет протокол (англ. Internet Protocol)
Integrated
Раздел VI. Технические требования
420
ISO
Международная организация стандартизации
International Standards Organization)
ITI
Инфраструктура ИТ (англ. IT Infrastructure)
JDBC
KB
(англ.
Платформенно-независимый промышленный стандарт
взаимодействия Java-приложений с различными СУБД
(англ. Java Database Connectivity)
Килобайт (англ. Kilobyte)
LAN
Локальная сеть (англ. Local area network)
LDAP
Протокол прикладного уровня для доступа к службе
каталогов X.500, разработанный IETF как облегчённый
вариант разработанного ITU-T протокола DAP. (англ.
Lightweight Directory Access Protocol)
LOINC
Универсальный стандарт для идентификации медицинских
врачебных и лабораторных наблюдений. (англ. Logical
Observation Identifiers Names and Codes)
MB
Мегабайт (англ. Megabyte)
MDX
Язык запросов для простого и эффективного доступа к
многомерным структурам данных, наподобие языка SQL
для реляционных баз данных (англ. Multi-Dimensional
eXpressions Language)
ODBC
Программный интерфейс доступа к базам данных,
разработанный фирмой Microsoft, в сотрудничестве с Simba
Technologies на основе спецификаций Call Level Interface,
который разрабатывался организациями SQL Access Group,
X/Open и Microsoft. (англ. Open Database Connectivity)
OLAP
Технология обработки данных, заключающаяся в
подготовке суммарной информации на основе больших
массивов данных, структурированных по многомерному
принципу (англ. Online Analytical Processing)
OLTP
Транзакционная система — обработка транзакций в
реальном времени. Способ организации БД, при котором
система работает с небольшими по размерам транзакциями,
но идущими большим потоком, и при этом клиенту
требуется от системы минимальное время отклика. (англ.
Online Transactional Processing)
OWASP
Открытый проект обеспечения безопасности вебприложений (англ. Open Web Application Security Project)
PaaS
Платформа как услуга (англ. Platform as a Service)
PDQ
Запрос демографических данных пациента (англ. Patient
Раздел VI. Технические требования
421
Demographic Query)
PIX
Идентификация пациентов по перекрестным ссылкам
(профиль IHE) (англ. Patient Identifier Cross-Reference)
PKI
Инфраструктура
Infrastructure)
PMI
Главный регистр пациентов (англ.Patient Master Index)
RAM
Один из видов памяти компьютера, позволяющий
единовременно получить доступ к любой ячейке по её
адресу на чтение или запись. (англ.Random Access memory)
REST
Стиль
построения
архитектуры
распределенного
приложения (англ.Representational State Transfer)
SaaS
Программное обеспечение как услуга (англ.Software as a
Service)
SAML
Язык разметки декларации безопасности (англ.Security
Assertion Markup Language)
SDK
Комплект средств разработки, который позволяет
специалистам по программному обеспечению создавать
приложения для определённого пакета программ,
программного обеспечения базовых средств разработки,
аппаратной платформы, компьютерной системы, игровых
консолей, операционных систем и прочих платформ (англ.
Software Development Kit).
SNOMED-CT
Систематизированная медицинская номенклатура —
Клинические термины (англ. Systematized Nomenclature Of
Medicine Clinical Terms)
SOA
Сервис-ориентированная архитектура (англ.Service-oriented
architecture)
SOAP
протокол обмена структурированными сообщениями в
распределённой вычислительной среде (англ. Simple Object
Access Protocol)
SQL
Универсальный компьютерный язык, применяемый для
создания, модификации и управления данными в
реляционных базах данных (англ. Structured Query
Language)
SSL
Криптографический протокол, который обеспечивает
безопасность связи. Он использует асимметричную
криптографию для аутентификации ключей обмена,
симметричное
шифрование
для
сохранения
конфиденциальности (англ. Secure Sockets Layer)
SSO
Технология
открытых
единого
ключей
входа
—
(англ.Public
технология,
Key
при
Раздел VI. Технические требования
422
использовании которой пользователь переходит из одного
раздела портала в другой без повторной аутентификации.
(англ. Single Sign On)
TCP
Один из основных протоколов передачи, данных Интернета,
предназначенный для управления передачей данных в сетях
и подсетях TCP/IP. Выполняет функции протокола
транспортного уровня в стеке протоколов TCP/IP (англ.
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
XML описание для web приложений работающих по
протоколу HTTP (как правило REST веб сервисы).
Позиционируется как эквивалент WSDL для REST. WADL
моделирует ресурсы предоставляемые сервисом и
взаимосвязи между ними.
(англ. Web Application
Description Language)
WCAG
Руководство по доступности Интернет-ресурсов.
Web Content Accessibility Guidelines)
WLAN
Беспроводная локальная сеть (англ. Wireless LAN)
WS
WSDL
XCA
(англ.
Веб сервис (англ. Web Service)
Язык описания веб-сервисов и доступа к ним, основанный
на языке XML. (англ. Web Services Description Language)
Доступ между сообществами (профиль
Community Access)
IHE) (англ. Cross-
Раздел VI. Технические требования
423
XD-LAB
Обмен документами лабораторных отчетов между
предприятиями (профиль IHE) (англ. Cross Enterprise
Document Sharing of Lab Reports)
XDS
Обмен документами между предприятиями (профиль IHE)
(англ. Cross-Enterprise Document Sharing)
XDS-MS
Обмен документами медицинских резюме (эпикризов)
между предприятиями (профиль IHE) (англ. Cross Enterprise
Document Sharing of Medical Summaries)
XML
Рекомендованный Консорциумом Всемирной паутины язык
разметки (англ. Extensible Markup Language - расширяемый
язык разметки)
XPHR
Обмен персональными медицинскими записями (англ.
Exchange of Personal Health Records)
XSL
Рекомендации консорциума W3C, описывающие языки
преобразования и визуализации XML-документов (англ.
Extensible Style sheet Language)
Раздел VI. Технические требования
424
B. БИЗНЕС ФУНКЦИИ И ТРЕБОВАНИЯ К ПРОИЗВОДИТЕЛЬНОСТИ
Целью этого раздела является определение ключевых бизнес- и функциональных
требований к поставке и установке Системы.
1.1 Бизнес требования к Системе
1.1.1. Текущая ситуация ИКТ МЗСР РК
1.1.1.1.
Предполагаемые изменения электронного здравоохранения в РК
Правительство РК приняло новую стратегию «Концепция развития
электронного здравоохранения Республики Казахстан на 2013-2020 годы», которая
определяет основные направления изменений электронного здравоохранения. В
соответствии с этой стратегией, ожидается, что новая архитектура будет служить
основой всех преобразований. Далее изложены основные свойства нового решения:
Электронное
здравоохранение
будет
основываться
на
принципах
интероперабельности, включающих: общие словари, классификаторы, номенклатуры,
направленные
на
создание
единой
информационной/
семантической
интероперабельности в области электронного здравоохранения;
- Создание общих и совместно используемых идентификаторов для электронного
здравоохранения РК: Идентификатор пациентов, идентификатор медицинских
работников (специалистов), а идентификатор организаций здравоохранения,
идентификаторы других ресурсов;
- Создание общей системы электронных паспортов здоровья, которая будет
расположена в центре и содержать записи о здоровье всех пациентов, и при
необходимости будет реплицироваться в локальные серверы;
- Предоставление вычислительной инфраструктуры, состоящей из 2-х центров
обработки данных, способных заменить друг друга в случае инцидентов;
- Установление технологии облачных вычислений, позволяющих обеспечить
соответствующие облачные сервисы: инфраструктура как услуга (IaaS), платформа как
услуга (PaaS) и программное обеспечение как услуга (SaaS);
- Эксплуатация на основе сервис-ориентированной архитектуры, что позволяет
повторно использовать функциональные возможности существующих систем и
обеспечить подключение к электронному правительству РК;
- Интеграция существующих систем и веб-приложений в платформе
интеграции/интероперабельности здравоохранения (далее – Платформа) и т.д.
Некоторые из подходов по формированию системы электронного здравоохранения
предусматривают:
- Системы электронного здравоохранения будут разработаны не только
централизованно за счет республиканского бюджета, но будет обеспечена
возможность для медицинских организаций приобретать информационные системы и
приложения самостоятельно;
Раздел VI. Технические требования
425
- В целях обеспечения интероперабельности, будет разработан набор требований
совместимости, и информационные системы будут сертифицированы на соответствие
стандартам МЗСР РК;
- В целях стимулирования развития рынка электронного здравоохранения,
правительство будет устанавливать специальные гранты и правила софинансирования
для ЛПО желающих компьютеризировать свою медицинскую деятельность;
- Правительство будет оценивать и контролировать потенциальные риски и принимать
решения, которые будут способствовать решению рисков (например, пропускная
способность каналов связи, выравнивание между потребностями здравоохранения и
ИКТ, обеспечения совместимости и т. д.);
- Министерство здравоохранения и социального развития ускорит процесс создания
правил и стандартов для улучшения взаимодействия между участниками процесса
электронного здравоохранения.
Рис.1. Общая архитектура национального электронного здравоохранения
Раздел VI. Технические требования
426
Более детальное описание изложено в «Концепции развития электронного
здравоохранения Республики Казахстан на 2013-2020 годы», доступной на веб-сайте
МЗСР РК.
1.1.2. Принципы, которым должна следовать Система
Следующие принципы применяются к разработке, конфигурации и использованию
Системы:
 Принцип законности, который предполагает создание, использование и
сопровождение ИС в соответствии с национальной правовой базой с
международными нормами и стандартами в этой области;
 Принцип
многоуровневой
архитектуры,
который
предполагает
самостоятельное развитие подсистем в соответствии со стандартами
интерфейса для каждого уровня;
 Принцип безопасных данных, который обеспечивает ввод данных в Систему
только с помощью прошедших проверку и авторизованных каналов;
 Принцип информационной безопасности, который предполагает обеспечение
надлежащего уровня целостности, избирательности, доступности и
эффективности для защиты данных от потери, изменения, уничтожения и
несанкционированного доступа;
 Принцип
конфиденциальности
данных,
который
предполагает
осуществление процедур, которые будут гарантировать доступ к данным только
в соответствии с национальной политикой и международными стандартами к
конфиденциальности личных данных, доступ в соответствии с согласием
пациента, возможностью шифровать сохраненные данные;
 Принцип прозрачности, который предполагает, что Система является
модульной структурой, и будет использовать прозрачные/ открытые стандарты
в области ИКТ;
 Принцип
расширения,
который
предполагает
расширение
и
совершенствование Системы с помощью новых функций и улучшения
существующей функциональности;
 Принцип приоритета первого лица/ уникального центра, который допускает
существование должностного ответственного лица высокого уровня, который
имеет достаточно прав для принятия решений и координации деятельности по
созданию, интеграции и использованию Системы;
 Принцип
масштабируемости,
который
предполагает
постоянную
производительность приложений и взаимосвязей с приращением объемов
данных и пользователей;
 Принцип простоты и удобства пользователей, который предполагает, что все
функции и инструменты, доступные для целевых ролей, основаны на
визуальных инструментах, эргономичны и интуитивно понятны.
Раздел VI. Технические требования
427
1.1.3. Бизнес-требования к Системе
Примечание 1. Следующие ключевые слова (т.е. нормативные глаголы) БУДУТ
использоваться, чтобы передать требования соответствия.
• СЛЕДУЕТ - для указания обязательного требования, подлежащего исполнению
(реализации) для того, чтобы соответствовать. Синонимом «ОБЯЗАН». Другой
используемый синоним «ДОЛЖЕН».
• НЕ СЛЕДУЕТ - чтобы указать запрещенное действие. Синоним «запрещено».
• СЛЕДОВАЛО БЫ - для указания дополнительного рекомендуемого действия,
которое особенно подходит, без упоминания или исключения других. Синоним
«разрешено и рекомендовано».
• МОЖЕТ - чтобы указать необязательные, допустимые действия. Синоним
«разрешено».
Примечание 2. В таблицах с бизнес- и функциональными
используются следующие категории (типы) или требования:
требованиями,
M - означает минимальное обязательное требование; такое требование, которому
поставляемое решение обязательно должно соответствовать; полное или частичное
отсутствие соответствия такому требованию может привести к отклонению
предложения участника.
D - желательные требования; отсутствие соответствия данному требованию не
приведет к отклонению предложения участника, а соответствие позволит повысить
конкурентоспособность предложения.
I - означает информация, добавляется для прояснения других требований.
Ссылка на требования в тексте будет отличаться от ссылки на главы и части в явном
виде:
Ссылка на требования явно будет содержать слово «требование», «req.» или R,
например R1.1 - ссылка на требование 1.1;
- Ссылки на главы будут с префиксом «глава», «раздел», или р, например, «p.1.1.1»
указывает на раздел 1.1.1 и не является требованием.
Таблица ниже содержит список бизнес-требований, которым должны соответствовать
поставляемая Система и связанные с ней системы/сервисы.
1.1.3.1.
№
Тип
Требование
Общие бизнес-требования к Системе
R1
R1.1
Общие бизнес-требования
M
Механизм лицензирования для Системы в рамках данного контракта
предоставляет право использовать все ее модули и составные части
для количества пользователей, достаточного для полноценного
функционирования медицинской организации (размер организации
можно оценить из описания в Приложении 7), в течение
Раздел VI. Технические требования
428
неограниченного времени, неограниченного количества серверов,
снимая все прочие возможные ограничения. Не допускаются
ежегодные лицензионные сборы; полная стоимость лицензии
включает в себя все расходы на лицензирование Системы.
R1.2
M
В рамках данного Контракта должна быть обеспечена
интероперабельность
Системы
с
национальной
системой
электронного здравоохранения согласно требованиям R7. Общая
схема взаимодействия с национальной системой электронного
здравоохранения представлена на Рисунке 1.
R1.3
М
Обобщенная архитектура комплексной информационной системы
здравоохранения, которой должна соответствовать Система,
представлена на рисунке 2
R1.4
М
Система должна представлять собой веб-приложение
R1.5
М
Система должна иметь способность тонкой настройки, чтобы
обеспечить
конфигурацию
под
потребности
конкретной
Организации без необходимости новой разработки (или включая
малую доработку)
R1.6
М
Поставщик в рамках данного Контракта должен обеспечить
интероперабельность Системы с Национальными инструментами
ЭПЗ (Репозиторий ЭПЗ, Национальные классификаторы и
идентификаторы, аналитическое хранилище, ЭПЗ-веб-сервисы) в
соответствии с R8
R1.7
М
Система должна обеспечивать конфиденциальность персональных
данных в процессе сохранения и передачи: шифрование
конфиденциальных данных в базе данных, шифрование данных при
передаче через каналы, использование безопасных протоколов
передачи и т.д.
R1.8
М
Система должна обеспечивать возможность использования
электронно-цифровой подписи для подписания и аутентификации
электронных документов, файлов и частей документов.
Необходимость использования электронно-цифровой подписи
должна
быть
конфигурируемой
на
уровне
системного
администратора.
R1.9
М
Система должна быть полностью работоспособной
Покупателю «под ключ» в соответствии с R15.2.
R1.10
М
Поставщик должен обеспечить не менее чем, но не ограничиваясь,
следующее: конфигурацию, развертывание, установку, тестирование
Системы. Поставщик должен обеспечить обучение пользователей,
администраторов (и другого персонала при необходимости).
и
сдана
Раздел VI. Технические требования
429
R1.11
М
Поставщик должен участвовать в процессе сертификации Системы
совместно с Поставщиком Платформы с целью проверки и
сертификации интероперабельности с национальными ресурсами и
инструментами ЭПЗ, в процедурах проведения аттестации и
испытаний Системы
R1.12
М
Поставщик должен обеспечить гарантийное обслуживание Системы
в течение 3 лет со дня передачи системы в эксплуатацию
Покупателю в соответствии с R13.4.
R1.13
М
В случае, если для полноценного функционирования Системы «под
ключ» необходимо наличие дополнительного лицензионного
программного обеспечения, Поставщик обязан обеспечить наличие
всех лицензий за свой счет и их передачу в собственность
Покупателя в рамках данного Контракта.
R1.14
М
Минимальные требования для каждого
соответствовать требованиям раздела R2
R1.15
D
Система должна иметь возможности интеграции со средами
разработки (IDE), как минимум для Java и Net Framework. Система
должна иметь в комплекте средства разработки (SDK), включающий
в себя: документацию, примеры кода как минимум для Java и Net
Framework, для конфигурирования функции Системы. Должна быть
возможность
расширения
функциональности
Системы
с
использованием средств разработки (SDK), входящих в состав
Системы.
R1.16
М
Механизм лицензирования для Системы в рамках данного контракта
не должен ограничивать изменения, вносимые с помощью средств
разработки (SDK), входящих в состав Системы. Внесение изменений
с помощью средств разработки (SDK), входящих в состав Системы,
не должно влиять на условия гарантийного обслуживания Системы.
Внесение изменений в Систему специалистами Заказчика
допускается после сдачи Системы в эксплуатацию.
R1.17
М
Поставщик должен обеспечить обслуживание и техническую
поддержку, включая предоставление новых версий продуктов
(согласно R13.3).
R1.18
М
Время отклика сервисов и компонентов Системы должно быть не
более 3-5 секунд, для не менее 80% случаев ввода данных или
запросов на просмотр данных (при скорости канала 1 Мб/с и
времени отклика не более 100 мс).
R1.19
М
Поставщик должен документировать и передать в электронном виде
конфигурационные файлы, и исходный код, компонентов Системы,
модуля
должны
Раздел VI. Технические требования
430
разработанные в рамках данного контракта.
R1.20
М
Система должна иметь тонкий клиент, для взаимодействия с
оборудованием допускается использование толстого клиента.
Рис.2. Обобщенная архитектура Системы.
Раздел VI. Технические требования
1.1.3.2. Требования
к
составу
автоматизированных Системой
431
процессов,
поддерживаемых
и
В Республике Казахстан организацией здравоохранения, осуществляющей
координацию деятельности медицинских организаций в области трансплантации
тканей и (или) органов (части органов) является «Республиканский координационный
центр по трансплантации» (далее - РКЦТ). Краткие сведения о РКЦТ приведены в
приложении 1 к настоящей технической спецификации.
Примечание 1: Разделение на модули является условным и не обязательным для
строгого соблюдения. Необходимым условием является наличие данных функций.
Примечание 2: При упоминании форм с приставкой /у описываются учетные формы
утвержденные приказом и.о. Министра здравоохранения РК №907 от 23 ноября 2010
года «Об утверждении форм первичной медицинской документации организаций
здравоохранения»
Примечание 3. В тексте используется следующая терминология:
- Возможный донор - пациент с тяжёлой травмой/заболеванием головного мозга,
находящийся на искусственной вентиляции легких.
- Потенциальный донор - пациент с подозрением на смерть мозга или с
травмой/заболеванием,
несовместимыми
с
жизнью,
нестабильной
гемодинамикой на фоне проводимого комплекса реанимационных мероприятий
и поддерживающей интенсивной терапии, с начатой диагностикой смерти
мозга.
- Актуальный донор - донор с установленной смертью мозга или необратимой
остановкой кровообращения с полученным письменным согласием законных
представителей донора на изъятие тканей и (или) органов (части органов).
- Ведение – создание, ввод, просмотр, редактирование, удаление данных.
№
Тип
Требования к автоматизированным процессам
R2
Модуль «Администрирование»
R2.1
R2.1.1
Требование
М
Настройка учетных записей пользователей Системы. Данный
процесс включает, как минимум:
R2.1.1.1 M
Создание учетных записей пользователей
R2.1.1.2 M
Редактирование учетных записей пользователей
R2.1.1.3 M
Удаление учетных записей пользователей
R2.1.2
М
Настройка прав пользователей Системы и четкого разграничения
Раздел VI. Технические требования
432
зон ответственности по региональному и административному
признаку. Данный процесс включает, как минимум:
R2.1.2.1 M
Персонифицированное назначение пользователю прав доступа
R2.1.2.2 M
Разграничение прав пользователей системы по ролям, группам и
уровню доступа с учётом иерархии объектов и принадлежности к
организационной структуре
R2.1.2.3 M
Редактирование прав доступа пользователей
R2.1.2.4 M
Удаление прав доступа пользователей
М
Конфигурирование критериев для автоматического подбора
подходящего реципиента из «листа ожидания». Данный процесс
включает, как минимум:
R2.1.3.1 M
Редактирование
(добавление/удаление)
критериев
для
автоматического подбора подходящего реципиента из «листа
ожидания»
R2.1.3.2 M
Редактирование весовых коэффициентов (баллов) критериев для
автоматического подбора подходящего реципиента из «листа
ожидания»
М
Конфигурирование регистрационных форм реципиентов/доноров.
Данный процесс включает, как минимум:
R2.1.4.1 M
Редактирование (добавление/удаление полей, редактирование
существующих полей) входных форм для регистрации
реципиентов/доноров/лиц, нуждающихся в трансплантации
R2.1.4.2 M
Добавление/удаление
входных
форм
для
регистрации
реципиентов/доноров/лиц, нуждающихся в трансплантации
R2.1.3
R2.1.4
Раздел VI. Технические требования
R2.1.4.3 M
433
Использование при создании и редактировании входных форм для
регистрации
реципиентов/доноров/лиц,
нуждающихся
в
трансплантации следующих функций:
 изменение настроек шрифта (стиль, размер, жирный,
подчеркнутый, курсив и т.д.)

изменение цвета шрифта

создание сложных входных форм с подразделами

возможность использования любого справочника в системе
для заполнения поля во входной формы

возможность использования любой сущности в базе данных
для заполнения поля во входной формы

возможность использования любой выборки из базы данных
для заполнения поля во входной формы

формирование правил заполнения входной формы: только
из списка, из списка с возможностью дополнения, в
свободной форме, из выборки и т.д.

создание новых справочников,
заполнении входной формы
используемых
при
R2.1.5
М
Импорт данных в Систему из файлов формата не менее чем xls,
xml.
R2.1.6
M
Ведение системных журналов. Данный процесс включает, как
минимум:
R2.1.7
M
Журнал создания, изменения и удаления записей в базе данных
R2.1.8
M
Журнал истории входов пользователей
R2.1.9
M
Журнал получения отчетных форм
R2.1.10 M
Журнал просмотра данных
R2.1.11 M
Журнал обработки данных (создание, изменение, удаление)
R2.1.12 M
Журнал действий по архивированию
R2.1.13 M
Журнал ошибок и аварийных остановок программы
R2.1.14 M
Журнал
синхронизации
с
внешними
(национальными)
справочниками, классификаторами, индексами и регистрами
R2.1.15 M
Архивирование журнала
Раздел VI. Технические требования
434
Модуль «Регистрация лица, нуждающегося в трансплантации»
R2.2
М
Регистрация в «Листе ожидания» лица, нуждающегося в
трансплантации по форме согласно Приложении 1-1, 1-2, 1-3 к
настоящей технической спецификации. Возможность регистрации
одного больного в нескольких «Листах ожидания». Данный
процесс включает, как минимум:
R2.2.1.1 M
Регистрация в «Листе ожидания» лица, нуждающегося в
трансплантации сердца по форме согласно Приложении 1-1 к
настоящей технической спецификации
R2.2.1.2 M
Регистрация в «Листе ожидания» лица, нуждающегося в
трансплантации печени по форме согласно Приложении 1-2 к
настоящей технической спецификации
R2.2.1.3 M
Регистрация в «Листе ожидания» лица, нуждающегося в
трансплантации почек по форме согласно Приложении 1-3 к
настоящей технической спецификации
R2.2.1.4 M
Регистрация одного больного в нескольких «Листах ожидания»
(при необходимости)
R2.2.1.5 M
Возможность печати информации о пациенте согласно
Приложении 1-1, 1-2, 1-3 к настоящей технической спецификации.
R2.2.1.6 M
Возможность экспорта информации о пациенте согласно
Приложении 1-1, 1-2, 1-3 к настоящей технической спецификации в
документы формата не менее чем pdf, xls, doc.
R2.2.1
M
Автоматическое получение информации о необходимости
регистрации в «Листе ожидания» лица, нуждающегося в
трансплантации, на основании информации из ИС МЗСР РК
(данный функционал должен быть реализован по мере готовности
необходимого для взаимодействия функционала на стороне
вышеуказанных ИС). Данный процесс включает, как минимум:
R2.2.2.1 M
Автоматическое получение информации от ИС МЗСР РК о
необходимости регистрации пациента в «Листе ожидания»
R2.2.2.2 M
Регистрация пациента в «Листе ожидания» согласно Приложении
1-1, 1-2, 1-3 к настоящей технической спецификации на основании
информации ИС МЗСР РК
R2.2.2.3 M
Регистрация одного больного в нескольких «Листах ожидания»
(при необходимости).
R2.2.2
Раздел VI. Технические требования
435
R2.2.2.4 M
Возможность печати информации о пациенте согласно
Приложении 1-1, 1-2, 1-3 к настоящей технической спецификации.
R2.2.2.5 M
Возможность экспорта информации о пациенте согласно
Приложении 1-1, 1-2, 1-3 к настоящей технической спецификации в
документы формата не менее чем pdf, xls, doc.
М
Ведение информации о текущем состоянии лица, нуждающегося в
трансплантации (улучшение или ухудшение течения заболевания в
связи
с
прогрессированием,
развитием
осложнений,
присоединением другого заболевания и другого). Данный процесс
включает, как минимум:
R2.2.3.1 M
Поиск пациента по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку.
R2.2.3.2 M
Ведение информации о текущем состоянии пациента: улучшении
или ухудшении течения заболевания, развитие осложнений,
присоединение другого заболевания и другом.
R2.2.3.3 M
Хранение в Системе истории изменения состояния пациента
R2.2.3.4 M
Просмотр истории изменения состояния пациента
R2.2.3.5 M
Возможность печати информации о состоянии пациента.
R2.2.3.6 M
Возможность печати истории изменения состояния пациента.
R2.2.3.7 M
Возможность экспорта информации о состоянии пациента
документы формата не менее чем pdf, xls, doc.
R2.2.3.8 M
Возможность экспорта истории изменения состояния пациента в
документы формата не менее чем pdf, xls, doc.
М
Мониторинг «Листа ожидания». Данный процесс включает, как
минимум:
R2.2.4.1 M
Поиск пациента по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку.
R2.2.4.2 M
Просмотр «Листа ожидания» (в том числе выдача ежедневной
информации в разрезе регионов о количестве пациентов взрослого
и детского возраста, количестве выбывших из «Листа ожидания» с
указанием причин, количестве новых случаев).
R2.2.3
R2.2.4
в
Раздел VI. Технические требования
436
R2.2.4.3 M
Сортировка и фильтрация «Листа ожидания» по ФИО пациента,
возрасту пациента, полу пациента, дате внесения в «Лист
ожидания», региону, медицинской организации, органу/ткани, в
трансплантации которой нуждается пациент и другому признаку.
R2.2.4.4 M
Возможность печати «Листа ожидания»
отфильтрованного и/или отсортированного).
R2.2.4.5 M
Возможность экспорта «Листа ожидания» (в том числе
отфильтрованного и/или отсортированного) в документы формата
не менее чем pdf, xls, doc.
(в
том
числе
Модуль «Стационарный трансплантационный координатор»
R2.3
М
Регистрация возможного донора по форме согласно Приложения 2
к настоящей технической спецификации. Данный процесс
включает, как минимум:
R2.3.1.1 M
Регистрация возможного донора согласно Приложения 2 к
настоящей технической спецификации
R2.3.1.2 M
Ведение информации о результатах обследования возможного
донора
R2.3.1.3 M
Просмотр ранее зарегистрированных возможных доноров с
возможностью сортировки и фильтрации по возрасту пациента,
полу пациента, диагнозу, дате поступления и другому признаку.
R2.3.1.4 M
Возможность печати информации о возможном доноре.
R2.3.1.5 M
Возможность экспорта информации о возможном доноре в
документы формата не менее чем pdf, xls, doc.
М
Регистрация потенциального донора по форме согласно
Приложения 2 к настоящей технической спецификации. Данный
процесс включает, как минимум:
R2.3.2.1 М
Регистрация потенциального донора согласно Приложения 2 к
настоящей технической спецификации
R2.3.2.2 М
Ведение информации о результатах обследования потенциального
донора
R2.3.2.3 М
Просмотр ранее зарегистрированных потенциальных доноров с
возможностью сортировки и фильтрации по возрасту пациента,
полу пациента, дате поступления в ОРИТ, по органу/ткани,
которые предполагается изъять и другому признаку.
R2.3.1
R2.3.2
Раздел VI. Технические требования
437
R2.3.2.4 М
Возможность формирования сводных отчетных форм по
зарегистрированным потенциальным донорам за определенный
период
R2.3.2.5 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным потенциальным донорам за определенный
период
R2.3.2.6
Возможность печати информации о потенциальном доноре
R2.3.2.7 М
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным потенциальным донорам за определенный
период в документы формата не менее чем pdf, xls, doc
R2.3.2.8 М
Возможность экспорта информации о потенциальном доноре в
документы формата не менее чем pdf, xls, doc
М
Регистрация актуального донора по форме согласно Приложения 2
к настоящей технической спецификации. Данный процесс
включает, как минимум:
R2.3.3.1 М
Регистрация актуального донора согласно Приложения 2 к
настоящей технической спецификации
R2.3.3.2 М
Ведение информации о результатах обследования актуального
донора
R2.3.3.3 М
Просмотр ранее зарегистрированных актуальных доноров с
возможностью сортировки и фильтрации по ФИО пациента,
возрасту пациента, полу пациента, по органу/ткани, которые
предполагается изъять и другому признаку.
R2.3.3.4 М
Формирование сводных отчетных форм по зарегистрированным
актуальным донорам за определенный период
R2.3.3.5 М
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным актуальным донорам за определенный период
R2.3.3.6 М
Возможность печати информации об актуальном доноре
R2.3.3.7 М
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным актуальным донорам в документы формата не
менее чем pdf, xls, doc
R2.3.3.8 М
Возможность экспорта информации об актуальном доноре в
документы формата не менее чем pdf, xls, doc
М
Ведение информации о текущем объективном статусе донора
R2.3.3
R2.3.4
Раздел VI. Технические требования
438
(возможного, потенциального, актуального), Данный процесс
включает, как минимум:
R2.3.4.1 M
Ведение информации о текущем объективном статусе донора
R2.3.4.2 M
Просмотр истории изменения объективного статуса донора
R2.3.4.3 M
Возможность печати информации об объективном статусе донора
R2.3.4.4 M
Возможность печати истории изменения объективного статуса
донора
R2.3.4.5 M
Возможность экспорта информации об объективном статусе
донора в документы формата не менее чем pdf, xls, doc.
R2.3.4.6 M
Возможность экспорта истории изменения объективного статуса
донора в документы формата не менее чем pdf, xls, doc.
Модуль «Лабораторные исследования»
R2.4
М
Ведение результатов выполненных исследований, включая, но, не
ограничиваясь информацией о результатах исследований
иммунологического типирования тканей высокого, среднего и
низкого разрешения лиц, рекомендованных к трансплантации и
потенциальных доноров (форма №410-10/у), информацией о
результатах индивидуальной пробы на совместимость «Кроссматч» потенциальных доноров и лиц, рекомендованных к
трансплантации (форма №410-11/у), результатов анализа на
определение лейкоцитарных антител кандидатов на пересадку
(форма №410-9/у). Данный процесс включает, как минимум:
R2.4.1.1 M
Поиск пациента по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку.
R2.4.1.2 M
Ведение результатов выполненных исследований, включая, но, не
ограничиваясь информацией о результатах исследований
иммунологического типирования тканей высокого, среднего и
низкого разрешения молекулярным и серологическим методом
лиц, рекомендованных к трансплантации и потенциальных доноров
(форма №410-10/у), информацией о результатах индивидуальной
пробы на совместимость «Кросс-матч» потенциальных доноров и
лиц, рекомендованных к трансплантации (форма №410-11/у),
результатов анализа на определение лейкоцитарных антител
кандидатов на пересадку (форма №410-9/у). Ввод результатов
выполненных лабораторных исследований
R2.4.1.3 M
Просмотр
результатов
исследований
R2.4.1
ранее
введенных
лабораторных
Раздел VI. Технические требования
439
R2.4.1.4 M
Возможность печати результатов лабораторных исследований,
включая, но, не ограничиваясь информацией о результатах
исследований иммунологического типирования тканей высокого,
среднего и низкого разрешения молекулярным и серологическим
методом
лиц,
рекомендованных
к
трансплантации
и
потенциальных доноров (форма №410-10/у), информацией о
результатах индивидуальной пробы на совместимость «Кроссматч» потенциальных доноров и лиц, рекомендованных к
трансплантации (форма №410-11/у), результатов анализа на
определение лейкоцитарных антител кандидатов на пересадку
(форма №410-9/у)
R2.4.1.5 M
Возможность экспорта результатов лабораторных исследований в
документы формата не менее чем pdf, xls, doc.
Модуль «Региональный трансплантационный координатор»
R2.5
М
Формирование запроса на исключение из «Листа ожидания» с
указанием причины (смерть, переезд, отсутствие необходимости в
трансплантации, появление противопоказаний к трансплантации и
другое). Данный процесс включает, как минимум:
R2.5.1.1 M
Ввод заявки на исключение из «Листа ожидания» с указанием
причины (смерть, переезд, отсутствие необходимости в
трансплантации, появление противопоказаний к трансплантации,
отказ от трансплантации и другое)
R2.5.1.2 M
Редактирование/удаление заявки на исключение
из «Листа
ожидания» неотправленной на рассмотрение республиканскому
трансплантационному координатору
R2.5.1.3 M
Отправка заявки на исключение
из «Листа ожидания» на
рассмотрение
республиканскому
трансплантационному
координатору
R2.5.1.4 M
Возможность печати заявки на исключение из «Листа ожидания».
R2.5.1.5 M
Возможность экспорта заявки на исключение
из «Листа
ожидания» в документы формата не менее чем pdf, xls, doc.
М
Мониторинг доноров (возможных, потенциальных, актуальных, а
также добровольных). Данный процесс включает, как минимум:
R2.5.2.1 M
Просмотр списка возможных доноров с возможностью сортировки
и фильтрации по возрасту пациента, полу пациента, диагнозу, дате
поступления и другому признаку.
R2.5.1
R2.5.2
Раздел VI. Технические требования
440
R2.5.2.2 M
Просмотр списка потенциальных доноров с возможностью
сортировки и фильтрации по возрасту пациента, полу пациента,
дате поступления в ОРИТ, по органу/ткани,
которые
предполагается изъять и другому признаку.
R2.5.2.3 M
Просмотр списка актуальных доноров с возможностью сортировки
и фильтрации по ФИО пациента, возрасту пациента, полу
пациента, по органу/ткани, которые предполагается изъять и
другому признаку.
R2.5.2.4 M
Просмотр списка добровольных доноров с возможностью
сортировки и фильтрации по возрасту пациента, полу пациента,
дате регистрации и другому признаку.
R2.5.2.5 M
Поиск пациента по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку.
R2.5.2.6 M
Просмотр списка лиц, исключенных из списка добровольных
доноров (отказ от донации, появление противопоказаний к
донации, смерть и иные причины).
R2.5.2.7 M
Просмотр истории изменения списка возможных доноров
R2.5.2.8 M
Просмотр истории изменения списка потенциальных доноров
R2.5.2.9 M
Просмотр истории изменения списка актуальных доноров
R2.5.2.10 M
Просмотр истории изменения списка добровольных доноров
R2.5.2.11 M
Ведение данных ежедневного отчета согласно Приложения 6 к
настоящей Технической спецификации
R2.5.2.12 M
Формирование сводных отчетных форм по зарегистрированным
донорам
(возможным,
потенциальным,
актуальным)
за
определенный период
R2.5.2.13 M
Формирование сводных отчетных форм по зарегистрированным
добровольным донорам за определенный период
R2.5.2.14 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным донорам (возможным, потенциальным,
актуальным).
R2.5.2.15 M
Возможность
печати
сводных
отчетных
зарегистрированным добровольным донорам.
форм
по
Раздел VI. Технические требования
441
R2.5.2.16 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным донорам (возможным, потенциальным,
актуальным) в документы формата не менее чем pdf, xls, doc
R2.5.2.17 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным добровольным донорам в документы формата
не менее чем pdf, xls, doc
R2.5.2.18 M
Возможность печати информации о зарегистрированном доноре
(возможном, потенциальном, актуальном, добровольном).
R2.5.2.19 M
Возможность экспорта информации о зарегистрированном доноре
(возможном, потенциальном, актуальном, добровольном) в
документы формата не менее чем pdf, xls, doc
М
Регистрация добровольных прижизненных доноров (то есть лиц,
изъявивших согласие на изъятие одного из своих парных органов
или части органа/ткани) с возможностью проверки наличия
нотариально заверенного согласия/отказа, путем взаимодействия с
государственной информационной системой Единая нотариальная
информационная
система
посредством
платформы
информатизации и интероперабельности здравоохранения согласно
Приложения 2-1 к настоящей технической спецификации. Данный
процесс включает, как минимум:
R2.5.3
R2.5.3.1 M
Ведение информации о добровольном прижизненном доноре
R2.5.3.2 M
Выбор конкретного реципиента добровольным прижизненным
донором (по желанию донора)
R2.5.3.3 M
Проверка наличия нотариально заверенного согласия быть
донором,
путем
взаимодействия
с
государственной
информационной системой Единая нотариальная информационная
система
посредством
платформы
информатизации
и
интероперабельности здравоохранения
R2.5.3.4 M
Ведение информации об отказе быть донором
R2.5.3.5 M
Проверка наличия нотариально заверенного отказа от донорства,
путем взаимодействия с государственной информационной
системой Единая нотариальная информационная система
посредством платформы информатизации и интероперабельности
здравоохранения
R2.5.3.6 M
Возможность печати информации о добровольном прижизненном
доноре.
Раздел VI. Технические требования
442
R2.5.3.7 M
Формирование сводных отчетных форм по зарегистрированным
добровольным донорам за определенный период
R2.5.3.8 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным добровольным донорам за определенный
период
R2.5.3.9 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным добровольным донорам в документы формата
не менее чем pdf, xls, doc.
R2.5.3.10 M
Формирование сводных отчетных форм по зарегистрированным
отказам быть донором за определенный период
R2.5.3.11 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным отказам быть донором за определенный
период
R2.5.3.12 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным отказам быть донором в документы формата
не менее чем pdf, xls, doc.
R2.5.3.13 M
Возможность
экспорта
информации
о
добровольном
прижизненном доноре в документы формата не менее чем pdf, xls,
doc.
М
Регистрация добровольных посмертных доноров (то есть лиц,
изъявивших согласие на изъятие после смерти своего органа/части
органа и/или ткани) с возможностью прикрепления сканированной
копии согласия/отказа согласно Приложения 2-1 к настоящей
технической спецификации. Данный процесс включает, как
минимум:
R2.5.4
R2.5.4.1 M
Ведение информации о добровольном посмертном доноре
R2.5.4.2 M
Выбор конкретного реципиента
донором (по желанию донора)
R2.5.4.3 M
Прикрепление сканированной копии нотариально заверенного
согласия
R2.5.4.4 M
Ведение информации об отказе быть донором
R2.5.4.5 M
Прикрепление сканированной копии нотариально заверенного
отказа
R2.5.4.6 M
Возможность печати информации о добровольном посмертном
доноре.
добровольным
посмертным
Раздел VI. Технические требования
443
R2.5.4.7 M
Возможность экспорта информации о добровольном посмертном
доноре в документы формата не менее чем pdf, xls, doc.
R2.5.4.8 M
Формирование сводных отчетных форм по зарегистрированным
добровольным донорам за определенный период
R2.5.4.9 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным добровольным донорам за определенный
период
R2.5.4.10 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным добровольным донорам в документы формата
не менее чем pdf, xls, doc.
R2.5.4.11 M
Формирование сводных отчетных форм по зарегистрированным
отказам быть донором за определенный период
R2.5.4.12 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным отказам быть донором за определенный
период
R2.5.4.13 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным отказам быть донором в документы формата
не менее чем pdf, xls, doc.
Модуль «Республиканский трансплантационный координатор»
R2.6
R2.6.1
М
Ведение
реестра
доноров
органов/части
органа
и/или
ткани(создание записей, редактирование, удаление, просмотр).
Данный процесс включает, как минимум:
R2.6.1.1 M
Ведение информации о донорах органов/части органа и/или ткани
R2.6.1.2 M
Исключение из регистра донора с указанием причины
R2.6.1.3 M
Поиск пациента по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку.
R2.6.1.4 M
Возможность печати информации о донорах органов/части органа
и/или ткани.
R2.6.1.5 M
Возможность экспорта информации о донорах органов/части
органа и/или ткани в документы формата не менее чем pdf, xls, doc.
R2.6.1.6 M
Формирование сводных отчетных форм по зарегистрированным
донорам органов/части органа и/или ткани
Раздел VI. Технические требования
444
R2.6.1.7 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным донорам органов/части органа и/или ткани
R2.6.1.8 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным донорам органов/части органа и/или ткани в
документы формата не менее чем pdf, xls, doc.
R2.6.1.9 M
Формирование сводных отчетных форм по исключенным из
регистра донорам органов/части органа и/или ткани
R2.6.1.10 M
Возможность печати сводных отчетных форм по исключенным из
регистра донорам органов/части органа и/или ткани
R2.6.1.11 M
Возможность экспорта сводных отчетных форм по исключенным
из регистра донорам органов/части органа и/или ткани в документы
формата не менее чем pdf, xls, doc.
М
Ведение «Листа ожидания» (создание записей, редактирование,
удаление, просмотр). Данный процесс включает, как минимум:
R2.6.2
R2.6.2.1 M
Ведение «Листа ожидания»
R2.6.2.2 M
Рассмотрение запроса Регионального трансплантационного
координатора на исключение из «Листа ожидания»
R2.6.2.3 M
Исключение пациента из «Листа ожидания» с указанием причины
R2.6.2.4 M
Возможность печати информации о лицах, нуждающихся в
трансплантации
R2.6.2.5 M
Возможность экспорта информации о лицах, нуждающихся в
трансплантации в документы формата не менее чем pdf, xls, doc
R2.6.2.6 M
Формирование сводных отчетных форм по зарегистрированным
лицам, нуждающимся в трансплантации органов/тканей, за
определенный период
R2.6.2.7 M
Возможность
печати
сводных
отчетных
форм
по
зарегистрированным лицам, нуждающимся в трансплантации
органов/тканей
R2.6.2.8 M
Возможность
экспорта
сводных
отчетных
форм
по
зарегистрированным лицам, нуждающимся в трансплантации
органов/тканей, за определенный период в документы формата не
менее чем pdf, xls, doc.
R2.6.2.9 M
Формирование сводных отчетных форм по пациентам,
исключенным из «Листа ожидания» за определенный период
Раздел VI. Технические требования
445
R2.6.2.10 M
Возможность печати сводных отчетных форм по пациентам,
исключенным из «Листа ожидания»
R2.6.2.11 M
Возможность экспорта сводных отчетных форм по пациентам,
исключенным из «Листа ожидания» в документы формата не менее
чем pdf, xls, doc.
М
Автоматическое направление по электронной почте напоминания о
необходимости
проведения
очередного
квартального
обследования. Данный процесс включает, как минимум:
R2.6.3.1 M
Автоматическое формирование списков больных, которые должны
пройти очередное квартальное обследование на определение
лейкоцитарных антител, за 10 дней до плановой даты сдачи
анализа.
R2.6.3.2 M
Автоматическое направление по электронной почте кандидату на
пересадку напоминания о необходимости проведения очередного
квартального обследования на определение лейкоцитарных антител
за 10 дней до даты сдачи анализа.
R2.6.3.3 M
Автоматическое направление по электронной почте напоминания
региональному и
республиканскому трансплантационному
координатору списков больных, которые должны пройти
очередное
квартальное
обследование
на
определение
лейкоцитарных антител, за 10 дней до плановой даты сдачи
анализа
М
Автоматический расчет баллов для определения места в «Листе
ожидания» по таблице критериев согласно Приложения 3 к
настоящей технической спецификации. Данный процесс включает,
как минимум:
R2.6.4.1 M
Автоматический расчет баллов для определения места в «Листе
ожидания» по таблице критериев согласно Приложения 3 к
настоящей технической спецификации
R2.6.4.2 M
Регулярный (не менее одного раза в сутки и при выявлении
актуального донора) автоматический пересчет баллов для
определения места в «Листе ожидания» по таблице критериев
согласно Приложения 3 к настоящей технической спецификации
М
Автоматический подбор группы потенциальных реципиентов по
донору. Данный процесс включает, как минимум:
R2.6.5.1 M
Поиск донора по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку.
R2.6.3
R2.6.4.
R2.6.5
Раздел VI. Технические требования
446
R2.6.5.2 M
Автоматический подбор группы потенциальных реципиентов по
донору.
R2.6.5.3 M
Возможность печати информации о лицах, подобранных в качестве
потенциальных реципиентов по донору.
R2.6.5.4 M
Возможность экспорта информации о лицах, подобранных в
качестве потенциальных реципиентов по донору в документы
формата не менее чем pdf, xls, doc.
М
Автоматический подбор группы потенциальных реципиентов по
донору с учетом потребности в нескольких органах/тканях. Данный
процесс включает, как минимум:
R2.6.6.1 M
Поиск донора по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку.
R2.6.6.2 M
Автоматический подбор группы потенциальных реципиентов по
донору с учетом потребности в нескольких органах/тканях.
R2.6.6.3 M
Возможность печати информации о лицах, подобранных в качестве
потенциальных реципиентов по донору с учетом потребности в
нескольких органах/тканях
R2.6.6.4 M
Возможность экспорта информации о лицах, подобранных в
качестве потенциальных реципиентов по донору с учетом
потребности в нескольких органах/тканях в документы формата не
менее чем pdf, xls, doc.
М
Автоматический подбор группы доноров по больному,
нуждающемуся в пересадке. Данный процесс включает, как
минимум:
R2.6.7.1 M
Поиск больного по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку или выбор больного
из «Листа ожидания».
R2.6.7.2 M
Автоматический подбор группы
нуждающемуся в пересадке.
R2.6.7.3 M
Возможность печати информации о лицах, подобранных в качестве
потенциальных доноров по больному.
R2.6.7.4 M
Возможность экспорта информации о лицах, подобранных в
качестве потенциальных доноров по больному в документы
формата не менее чем pdf, xls, doc.
R2.6.6
R2.6.7
доноров
по
больному,
Раздел VI. Технические требования
447
М
Автоматический подбор группы доноров по больному,
нуждающемуся в пересадке с учетом потребности в нескольких
органах/тканях. Данный процесс включает, как минимум:
R2.6.8.1 M
Поиск больного по ФИО, ИИН, органу/части органа и/или ткани,
группе крови, rh фактору и другому признаку или выбор больного
из «Листа ожидания».
R2.6.8.2 M
Автоматический подбор группы доноров по больному,
нуждающемуся в пересадке с учетом потребности в нескольких
органах/тканях.
R2.6.8.3 M
Возможность печати информации о лицах, подобранных в качестве
потенциальных доноров по больному с учетом потребности в
нескольких органах/тканях.
R2.6.8.4 M
Возможность экспорта информации о лицах, подобранных в
качестве потенциальных доноров по больному с учетом
потребности в нескольких органах/тканях в документы формата не
менее чем pdf, xls, doc.
М
Ведение информации о решении консилиума о трансплантации.
Данный процесс включает, как минимум:
R2.6.9.1 M
Ведение информации о консилиуме (участники, место проведения,
дата и другое)
R2.6.9.2 M
Ведение информации о решении консилиума о трансплантации
R2.6.9.3 M
Возможность печати информации о консилиуме и принятом
решении.
R2.6.9.4 M
Возможность экспорта информации о консилиуме и принятом
решении в документы формата не менее чем pdf, xls, doc.
R2.6.8
R2.6.9
Модуль «Трансплантационная бригада»
R2.7
R2.7.1.
М
Ведение информации об отобранных донорских органах и тканях.
Данный процесс включает, как минимум:
R2.7.1.1 M
Ведение информации об отобранных донорских органах
R2.7.1.2 M
Ведение информации об отобранных донорских тканях
R2.7.1.3 M
Ведение информации об операции по отбору органов
(наименование медицинской организации, в которой произведена
операция, код МКБ-9, информация об анестезии и другое)
Раздел VI. Технические требования
448
R2.7.1.4 M
Возможность печати информации об отобранных донорских
органах и тканях.
R2.7.1.5 M
Возможность печати информации об операции по отбору органов
R2.7.1.6 M
Возможность экспорта информации об отобранных донорских
органах и тканях в документы формата не менее чем pdf, xls, doc.
R2.7.1.7 M
Возможность экспорта информации об операции по отбору органов
в документы формата не менее чем pdf, xls, doc.
R2.7.1.8 M
Формирование сводных отчетных форм по отобранным донорским
органам и тканям за определенный период
R2.7.1.9 M
Возможность печати сводных отчетных форм по отобранным
донорским органам и тканям
R2.7.1.10 M
Возможность экспорта сводных отчетных форм по отобранным
донорским органам и тканям в документы формата не менее чем
pdf, xls, doc.
R2.7.1.11 M
Формирование сводных отчетных форм по произведенным
операциям по отбору донорских органов/тканей за определенный
период
R2.7.1.12 M
Возможность печати сводных отчетных форм по произведенным
операциям по отбору донорских органов/тканей
R2.7.1.13 M
Возможность экспорта сводных отчетных форм по произведенным
операциям по отбору донорских органов/тканей в документы
формата не менее чем pdf, xls, doc.
М
Ведение информации о произведенных пересадках органов и
тканей. Данный процесс включает, как минимум:
R2.7.2.1 M
Ведение информации о пересажанных реципиенту донорских
органах/тканях
R2.7.2.2 M
Ведение информации об операции по трансплантации органов
(наименование медицинской организации, в которой произведена
операция, код МКБ-9, информация об анестезии и другое)
R2.7.2.3 M
Ведение информации о пред- и послеоперационном периоде, схеме
иммуносупрессивной терапии, послеоперационных осложнениях.
R2.7.2.4 M
Возможность печати информации о пересажанных реципиенту
R2.7.2
Раздел VI. Технические требования
449
донорских органах/тканях.
R2.7.2.5 M
Возможность печати информации об операции по пересадки
органов
R2.7.2.6 M
Возможность экспорта информации о пересажанных реципиенту
донорских органах/тканях в документы формата не менее чем pdf,
xls, doc
R2.7.2.7 M
Возможность экспорта информации об операции по пересадки
органов в документы формата не менее чем pdf, xls, doc
R2.7.2.8 M
Формирование сводных отчетных форм по пересаженным
донорским органам и тканям за определенный период
R2.7.2.9 M
Возможность печати сводных отчетных форм по пересаженным
донорским органам и тканям за определенный период
R2.7.2.10 M
Возможность экспорта сводных отчетных форм по пересаженным
донорским органам и тканям за определенный период в документы
формата не менее чем pdf, xls, doc
R2.7.2.11 M
Формирование сводных отчетных форм по произведенным
операциям по пересадки реципиенту органов/тканей за
определенный период
R2.7.2.12 M
Возможность печати сводных отчетных форм по произведенным
операциям по пересадки реципиенту органов/тканей за
определенный период
Модуль «Мониторинг состояния
произведена трансплантация»
R2.8
лиц,
которым
была
М
Ведение регистра лиц, которым была произведена трансплантация
(создание записей, редактирование, просмотр). Данный процесс
включает, как минимум:
R2.8.1.1 M
Ведение информации о лицах, которым была произведена
трансплантация
R2.8.1.2 M
Мониторинг состояния донора, от которого была произведена
трансплантация.
R2.8.1.3 M
Поиск пациента по ФИО, ИИН, пересаженному органу/части
органа и/или ткани, группе крови, rh фактору и другому признаку.
R2.8.1.4 M
Возможность печати информации о лицах, которым была
произведена трансплантация
R2.8.1
Раздел VI. Технические требования
450
R2.8.1.5 M
Возможность экспорта информации о лицах, которым была
произведена трансплантация в документы формата не менее чем
pdf, xls, doc.
М
Мониторинг состояния здоровья лиц, которым была произведена
трансплантация. Данный процесс включает, как минимум:
R2.8.2.1 M
Ведение информации о состоянии здоровья лиц, которым была
произведена трансплантация
R2.8.2.2 M
Ведение истории изменения состояния здоровья лиц, которым была
произведена трансплантация
R2.8.2.3 M
Мониторинг состояния лиц, которым
трансплантация от общего донора.
R2.8.2.4 M
Просмотр истории изменения состояния здоровья лиц, которым
была произведена трансплантация с возможностью сортировки и
фильтрации по возрасту пациента, полу пациента, дате
регистрации, трансплантированному органу и другому признаку.
R2.8.2.5 M
Поиск пациента по ФИО, ИИН, пересаженному органу/части
органа и/или ткани, группе крови, rh фактору и другому признаку.
R2.8.2.6 M
Возможность печати информации о состоянии здоровья лиц,
которым была произведена трансплантация
R2.8.2.7 M
Возможность печати истории изменения состояния здоровья лиц,
которым была произведена трансплантация
R2.8.2.8 M
Возможность экспорта информации о состоянии здоровья лиц,
которым была произведена трансплантация, в документы формата
не менее чем pdf, xls, doc.
R2.8.2.9 M
Возможность экспорта истории изменения состояния здоровья лиц,
которым была произведена трансплантация, в документы формата
не менее чем pdf, xls, doc.
R2.8.2
была
произведена
Модуль «Формирование аналитических и статистических
таблиц»
R2.9
R2.9.1
М
Отчет о проведенных аллогенных родственных трансплантациях
(по фамильный список реципиентов, доноров, исходов)
R2.9.2
М
Отчет о проведенных аллогенных неродственных трансплантациях
(по фамильный список реципиентов, доноров, исходов)
Раздел VI. Технические требования
451
R2.9.3
М
Отчет по летальным исходам больных, состоящих на «Листе
ожидания» (по возрастам, причине смерти, дате смерти)
R2.9.4
М
Отчет о проведенных эксплантациях: информация об отобранных
органах, причинах не произведенного отбора, медицинской
организации, где был произведен отбор
R2.9.5
М
Отчет о случаях констатации смерти мозга/остановки
кровообращения потенциального донора (по фамильный список,
даты смерти)
R2.9.6
М
Ежемесячные отчеты согласно Приложении 4, 5 к настоящей
Технической спецификации
R2.9.7
М
Ежедневный
отчет
регионального
трансплантационного
координатора согласно Приложения 6 к настоящей Технической
спецификации
R2.9.8
М
Все выходные формы должны иметь возможность распечатки и
сохранения в формате не менее чем xls, pdf, doc.
1.1.4. Правовые документы
Минимальный набор правовых актов, которые необходимо соблюсти:
7) Закон Республики Казахстан «О национальной безопасности Республики
Казахстан»
№
527-IV
от
6
января
2012
года
(http://online.zakon.kz/Document/?doc_id=31106860);
8) Указ Президента от 14 ноября 2011 года № 174 «О концепции информационной
безопасности РК 2016» (http://ru.government.kz/docs/u110000017420111114.htm);
9) Кодекс РК N 193-IV от 18 сентября 2009 года “О здоровье народа и системе
здравоохранения”;
10) Закон “О персональных данных и их защите” N 94-V от 21 мая 2013
(http://online.zakon.kz/Document/?doc_id=31396226);
11) Приказ и.о. Министра здравоохранения Республики Казахстан от 23 ноября
2010 года № 907 «Об утверждении форм первичной медицинской
документации организаций здравоохранения»;
12) Приказ и.о. Министра здравоохранения РК №75 от 10.02.2014 г «Об
утверждении технической документации по вопросам электронного
здравоохранения». (https://www.mzsr.gov.kz/node/319759);
13) Приказ Министра здравоохранения Республики от 29 марта 2013 года № 199 «О
мерах по развитию службы трансплантации органов и тканей в Республике
Казахстан»;
Раздел VI. Технические требования
452
14) Национальные НПА определяющие требования к ЭПЗ, ЭМЗ, процессам
электронного здравоохранения и техническим требованиям по взаимодействию
с центральными компонентами и ИС электронного здравоохранения РК;
15) Национальные НПА определяющие требования к процессам донации и
трансплантации тканей и (или) органов (части органов).
1.2 Требования к конфигурации системы
№
Ти
п
Требование
Требования к конфигурации системы
R3
Конфигурация к потребностям медицинских организаций
R3.1
R3.1.1
М
Система должна обеспечить возможность управления доступом к
функционалу на основе ролей. Система должна позволять
добавлять/удалять/редактировать роли и присвоить/отменить право
доступа к функционалу системы.
R3.1.2
М
Система должна иметь предустановленные роли в соответствии с
разделом 1.2.1 настоящей технической спецификации с
возможностью дальнейшего изменения (добавления новых ролей,
редактирования или удаления).
R3.1.3
М
Права доступа к различным модулям и функциям системы должны
быть предустановлены в соответствии с Таблицей 1 с
возможностью изменения прав доступа (добавления, удаления)
R3.1.4
М
Права доступа должны быть как минимум конфигурируемыми по
следующим аспектам: все права, создание, изменение, удаление,
просмотр.
R3.1.5
M
Система должна включать мастер отчетных форм, позволяющий
создавать и редактировать отчеты с использованием полей из базы
данных Системы
1.2.1
Описание ролей
1. Регистратор лица, нуждающегося в трансплантации – профильный специалист,
проводящий постоянное наблюдение за пациентом по поводу определенного
заболевания, являющегося причиной внесения данного пациента в «Лист
ожидания». Должности: заведующий отделением, профильный специалист,
врач, внештатный специалист управления здравоохранения, стационарный
трансплантационный
координатор,
региональный
трансплантационный
координатор, республиканский трансплантационный координатор
Раздел VI. Технические требования
453
2. Стационарный трансплантационный координатор – диспетчер и инициатор
донорства тканей и (или) органов (части органов) в медицинских организациях,
являющийся штатным сотрудником стационара. Должности: стационарный
трансплантационный координатор.
3. Лаборант – сотрудник лаборатории, в обязанности которого входит ввод в
Систему информации о лабораторных исследованиях доноров, реципиентов,
лиц, нуждающихся в трансплантации. Должности: лаборант, врач-лаборант,
специалист лаборатории.
4. Региональный трансплантационный координатор – врач, организатор
межгоспитального взаимодействия медицинских организаций в области
трансплантации тканей и (или) органов (части органов) в областных центрах
Республики Казахстан. Должности: региональный трансплантационный
координатор.
5. Республиканский трансплантационный координатор – сотрудник организации
здравоохранения, осуществляющей координацию деятельности медицинских
организаций в области трансплантации тканей и (или) органов (части органов).
Должности: врач координатор, сотрудник РКЦТ.
6. Лечащий врач – профильный специалист, проводящий постоянное наблюдение
за пациентом по поводу определенного заболевания, являющегося причиной
внесения данного пациента в «Лист ожидания», а также оказывающий
медицинскую помощь пациенту после трансплантации. Должности:
заведующий отделением, профильный специалист, врач, внештатный
специалист управления здравоохранения.
7. Администратор – специалист администрирующий (настройка учетных записей,
распределение прав доступа и другое) Систему. Должности: сотрудник РКЦТ.
Таблица 1 - Права доступа ролей к функциям модулей
№
1.
Требование
Роли
Модуль «Регистрация лица, нуждающегося в
трансплантации»
1.1.
Регистрация
в
«Листе
ожидания»
лица, Регистратор
лица,
нуждающегося в трансплантации по форме нуждающегося
в
согласно Приложении 1-1, 1-2, 1-3 к настоящей трансплантации
технической
спецификации.
Возможность
регистрации одного больного в нескольких
«Листах ожидания».
1.2.
Автоматическое
получение
информации
о Регистратор
лица,
необходимости регистрации в «Листе ожидания» нуждающегося
в
лица, нуждающегося в трансплантации, на трансплантации
основании информации из ИС МЗСР РК (данный
Раздел VI. Технические требования
454
функционал должен быть реализован по мере
готовности необходимого для взаимодействия
функционала на стороне вышеуказанных ИС).
1.3.
Ввод информации о текущем состоянии лица, Регистратор
лица,
нуждающегося в трансплантации (улучшение или нуждающегося
в
ухудшение течения заболевания в связи с трансплантации
прогрессированием,
развитием
осложнений,
присоединением другого заболевания и другим).
1.4.
Мониторинг «Листа ожидания».
2.
Регистратор
лица,
нуждающегося
в
трансплантации
Модуль «Стационарный трансплантационный
координатор»
2.1.
Регистрация возможного донора по форме Стационарный
согласно Приложения 2 к настоящей технической трансплантационный
спецификации.
координатор
2.2.
Регистрация потенциального донора по форме Стационарный
согласно Приложения 2 к настоящей технической трансплантационный
спецификации.
координатор
2.3.
Регистрация актуального донора по форме Стационарный
согласно Приложения 2 к настоящей технической трансплантационный
спецификации.
координатор
2.4.
Ввод информации о текущем объективном статусе Стационарный
состоянии донора (возможного, потенциального, трансплантационный
актуального),
координатор
3.
3.1.
Модуль «Лабораторные исследования»
Ввод результатов выполненных исследований, Лаборант
включая, но, не ограничиваясь информацией о
результатах исследования иммунологического
типирования тканей высокого, среднего и низкого
разрешения
лиц,
рекомендованных
к
трансплантации и потенциальных доноров (форма
№410-10/у),
информацией
о
результатах
индивидуальной пробы на совместимость «Кроссматч»
потенциальных
доноров
и
лиц,
рекомендованных к трансплантации (форма №41011/у), результатов анализа на определение
лейкоцитарных антител кандидатов на пересадку
Раздел VI. Технические требования
455
(форма №410-9/у).
4.
Модуль «Региональный трансплантационный
координатор»
4.1.
Формирование запроса на исключение из «Листа Региональный
ожидания» с указанием причины (смерть, переезд, трансплантационный
отсутствие необходимости в трансплантации, координатор
появление противопоказаний к трансплантации и
другое).
4.2.
Мониторинг доноров (возможных, потенциальных, Региональный
актуальных, а также добровольных).
трансплантационный
координатор
4.3.
Регистрация
добровольных
прижизненных Региональный
доноров (то есть лиц, изъявивших согласие на трансплантационный
изъятие одного из своих парных органов или части координатор
органа/ткани) с возможностью прикрепления
сканированной копии нотариально заверенного
согласия/отказа согласно Приложения 2-1 к
настоящей технической спецификации.
4.4.
Регистрация добровольных посмертных доноров Региональный
(то есть лиц, изъявивших согласие на изъятие трансплантационный
после смерти своего органа/части органа и/или координатор
ткани)
с
возможностью
прикрепления
сканированной копии согласия/отказа согласно
Приложения 2-1 к настоящей технической
спецификации.
5.
Модуль
«Республиканский
трансплантационный координатор»
5.1.
Ведение реестра доноров органов/части органа Республиканский
и/или ткани (создание записей, редактирование, трансплантационный
удаление, просмотр).
координатор
5.2.
Ведение «Листа ожидания» (создание записей, Республиканский
редактирование, удаление, просмотр).
трансплантационный
координатор
5.3.
Автоматическое направление по электронной
почте напоминания о необходимости проведения
очередного квартального обследования.
5.4.
Автоматический расчет баллов для определения
Раздел VI. Технические требования
456
места в «Листе ожидания» по таблице критериев
согласно Приложения 3 к настоящей технической
спецификации.
5.5.
Автоматический подбор группы потенциальных Республиканский
реципиентов по донору.
трансплантационный
координатор
5.6.
Автоматический подбор группы потенциальных Республиканский
реципиентов по донору с учетом потребности в трансплантационный
нескольких органах/тканях.
координатор
5.7.
Автоматический подбор группы доноров
больному, нуждающемуся в пересадке.
5.8.
Автоматический подбор группы доноров по Республиканский
больному, нуждающемуся в пересадке с учетом трансплантационный
потребности в нескольких органах/тканях.
координатор
5.9.
Ввод решения консилиума о трансплантации.
6.
по Республиканский
трансплантационный
координатор
Республиканский
трансплантационный
координатор
Модуль «Трансплантационная бригада»
6.1.
Ввод информации об отобранных донорских Трансплантационная
органах и тканях.
бригада
6.2.
Ввод информации о произведенных пересадках Трансплантационная
органов и тканей.
бригада
7.
Модуль «Мониторинг состояния лиц, которым
была произведена трансплантация»
7.1.
Ведение регистра лиц, которым была произведена Республиканский
трансплантация
(создание
записей, трансплантационный
редактирование, просмотр).
7.2.
Мониторинг состояния здоровья лиц, которым Республиканский
была произведена трансплантация.
трансплантационный
Региональный
трансплантационный
координатор
8.
Модуль «Формирование
статистических таблиц»
аналитических
и
Раздел VI. Технические требования
457
8.1.
Отчет
о
случаях
констатации
смерти Республиканский
мозга/остановки кровообращения потенциального трансплантационный
донора (по фамильный список, даты смерти)
Региональный
трансплантационный
координатор
8.2.
Ежемесячные отчеты согласно Приложении 4, 5 к Республиканский
настоящей Технической спецификации
трансплантационный
Региональный
трансплантационный
координатор
8.3.
Ежедневный
отчет
регионального
трансплантационного
координатора
согласно
Приложения 6 к настоящей Технической
спецификации
8.4.
Все выходные формы должны иметь возможность Республиканский
распечатки и сохранения в формате не менее чем трансплантационный
xls, pdf, doc.
Региональный
трансплантационный
координатор
9.
Республиканский
трансплантационный
Региональный
трансплантационный
координатор
Модуль «Администрирование»
9.1.
Настройка
Системы.
учетных
записей
пользователей Администратор
9.2.
Настройка прав пользователей Системы и четкого Администратор
разграничения
зон
ответственности
по
региональному и административному признаку.
9.3.
Конфигурирование критериев для автоматического Администратор
подбора подходящего реципиента из «листа
ожидания».
9.4.
Конфигурирование
регистрационных
реципиентов/доноров.
9.5.
Импорт данных в Систему из файлов формата не Администратор
менее чем xls, xml.
9.6.
Ведение системных журналов.
форм Администратор
Администратор
Раздел VI. Технические требования
458
1.2.2 Требования к времени реакции системы
№
Тип
Требование
Требования к времени реакции системы
R4
R4.1
M
Поиск пациента по ФИО или ИИН, а также связанных с
пациентом данных (результаты обследования, результаты
лабораторных исследований и другое) не должен занимать более 5
секунд для 80% случаев
R4.2
М
Поставщик в течение гарантийного срока должен обеспечивать
следующие параметры функционирования системы:
R4.3
М
Суммарное время простоя Системы по причинам, связанным с ее
работоспособностью не должно превышать 24 часов в год.
R4.4
М
Время однократного простоя Системы по причинам, связанным с
ее работоспособностью не должно превышать 2 часов.
1.2.3 Требования к информационной безопасности системы
№
Тип
Требование
Требования к информационной безопасности
R5
R5.1
M
Требования
безопасности
определяются
действующим
законодательством Республики Казахстан. Система должна
соответствовать требованиям информационной безопасности по
обеспечению
порогового
доступа,
защите
от
несанкционированного доступа и другого.
R5.2.
M
В системе должны быть предусмотрены средства защиты
информации от несанкционированного доступа, а именно:
R5.2.1
M
Идентификация пользователя на основе проверки имени (логина)
пользователя и пароля
R5.2.2
M
Возможность идентификации пользователя, основанной
цифровых сертификатах инфраструктуры открытых ключей
R5.2.3
M
Авторизация пользователя для доступа к информационновычислительным ресурсам Системы, требующим наличия
соответствующих разрешений
R5.2.4
M
Персонифицированное определение прав пользователей на ввод,
корректировку, просмотр данных
на
Раздел VI. Технические требования
459
R5.2.5
M
Персонифицированное определение прав пользователей на доступ
к ресурсам Системы
R5.2.6
M
Разграничение прав пользователей системы по ролям, группам и
уровню доступа с учётом иерархии объектов и принадлежности к
организационной структуре.
R5.2.7
M
Протоколирование работы пользователей
функциями и приложениями Системы
R5.2.8
M
Защиту
системных
файлов
от
изменения/повреждения
неавторизованными пользователями и программными процессами
R5.2.9
M
Должен вестись контрольный журнал всех обновлений в
библиотеках системных программ
R5.3
M
В системе должны быть реализованы не менее чем следующие
средства резервного копирования:
- автоматическое резервное копирование с возможностью
планирования
- удаленное управление созданием резервной копии
- полное и частичное резервное копирование
R5.4
M
Система должна обеспечивать целостность данных.
R5.5
M
Система должна предоставлять инструменты для шифрования
конфиденциальных данных во время хранения и в процессе
передачи в другие системы.
R5.6
M
Электронно-цифровая подпись (далее - регистрационное
свидетельство пользователя Национальным Удостоверяющим
Центром Республики Казахстан, ЭЦП) должна быть выпущена
НУЦ РК. Система должна обеспечить инструменты для цифровой
подписи документов (объектов) или частей документов,
когда/если это необходимо, и инструменты для аутентификации
подписей. Эта возможность должна быть реализована в сервисах
Системы (если это необходимо). Для обеспечения подтвреждения
полдинности ЭЦП и действительности открытого ключа ЭЦП,
Система должна осушествлять проверки подлинности ЭЦП
посредством сервисов НУЦ РК. (http://pki.gov.kz/index.php/ru/).
R5.7
M
Система должна соответствовать принципу «единой точки
доступа» - архитектура информационной инфраструктуры,
позволяющая иметь общую точку доступа (технология Single Sign
On) ко всем ее компонентам и ресурсам, что позволяет ввести
логин и пароль один раз и получить доступ ко всем компонентам
Системы без повторного ввода пароля.
с
критическими
Раздел VI. Технические требования
460
R5.8
M
Система должна обеспечивать авторизацию пользователей в
Системе, разграничение прав пользователей системы по ролям,
группам и уровню доступа с учётом иерархии объектов и
принадлежности к организационной структуре.
R5.9
M
В соответствии с нормативно-технической документацией по
информационной безопасности, утвержденной МЗСР РК, должно
быть реализовано следующее:
− длина пароля должна быть не менее 8 символов,
должны присутствовать буквы и цифры в верхнем и
нижнем регистрах;
− функция принудительной смены пароля;
− функция запрета использования в качестве пароля
«пустой» пароль;
− самостоятельная смена пароля пользователем;
− при введении неправильного пароля более трех раз
должен быть реализован метод CAPTCHA;
− журнал логирования действий всех пользователей,
предназначенный для просмотра истории изменений
основных событий Системы;
− функционал прерывания сессии при неактивности
через N количество времени.
1.2.4 Требования к атрибутам качества системы
№
R6
Тип
R6.1.
M
Система должна поддерживать ввод, получение и передачу данных
необходимых для работы ИС МЗСР РК используемых
Организацией и исключать необходимость повторного ввода
данных.
R6.2
M
Система должна обеспечивать сохранение всей накопленной на
момент отказа или выхода из строя информации при отказе любого
компонента Системы независимо от его назначения, с
последующим восстановлением после проведения ремонтных и
восстановительных работ
R6.3
M
Система должна иметь возможность гибкой настройки при
изменении внешней среды и конкретных задач пользователя без
замены модулей.
R6.4
M
Система должна быть высоко масштабируемой и позволять
Требование
Требования к атрибутам качества системы
Раздел VI. Технические требования
461
работать в системе неограниченному количеству пользователей.
Ограничения могут обуславливаться только техническими
характеристиками оборудования, а не характеристиками Системы
R6.5
M
Все функциональные возможности
разработаны в виде сервисов.
системы
должны
R6.6
M
Веб-сервисы Системы должны быть разработаны в соответствии с
СОА (Сервис-ориентированная архитектура) архитектурой.
R6.7
М
При реализации
сервисов взаимодействия обязательно
придерживаться стандарта МЗСР РК, касающегося взаимодействия
ИС
R6.8
M
Система должна предусматривать возможность конструирования
шаблонов утвержденных медицинских форм, доступных в пределах
самого решения, которые могут быть автоматизированы без
программирования или внесения изменений в программный код.
R6.9
M
Система должна обеспечивать разрешение
параллельной обработке объектов системы.
конфликтов
быть
при
1.2.5 Требования к пользовательскому интерфейсу
№
Тип
Требование
Требования к пользовательскому интерфейсу
R7
R7.1
M
Интерфейс должен быть рассчитан на преимущественное
использование манипулятора типа «мышь», то есть управление
системой должно осуществляться с помощью набора экранных
меню, кнопок, значков и тому подобных элементов
R7.2
M
Клавиатурный режим ввода должен использоваться главным
образом при заполнении и/или редактировании текстовых и
числовых полей экранных форм. Также должны быть
предусмотрены
горячие
клавиши
для
перехода
между
заполняемыми полями.
R7.3
M
Эргономические решения и дизайн интерфейсов по возможности
должны быть едиными для всех компонентов и модулей Системы
R7.4
M
Пользовательский интерфейс Системы должен быть многоязычным
и организован с поддержкой не менее чем государственного
(казахского) и русского языков. Исключения могут составлять
только системные сообщения, не подлежащие локализации или
стандартные административные приложения, входящие в состав
общесистемного программного обеспечения
Раздел VI. Технические требования
462
R7.5
M
Должен быть обеспечен доступ к электронному комплекту
эксплуатационной документации
R7.6
M
В Системе должна быть реализована контекстно-зависимая
справочная система, доступная из любых страниц веб-приложения,
где должны быть представлены ссылки на информацию
(Руководство пользователя, инструкции и др.) для работы, с
возможностью конфигурации без привлечения Потенциального
Поставщика на уровне Покупателя;
R7.7
M
В пользовательском интерфейсе Системы должно быть
предусмотрено визуальное выделение на экране атрибутов,
доступных оператору только для чтения
R7.8
M
В пользовательском интерфейсе Системы должно быть
предусмотрено визуальное выделение на экране атрибутов,
обязательных для заполнения
R7.9
M
Система должна обеспечивать корректную обработку аварийных
ситуаций, вызванных неверными действиями пользователей,
неверным форматом или недопустимыми значениями входных
данных. В указанных случаях Система должна выдавать
пользователю
соответствующие
сообщения,
после
чего
возвращаться в рабочее состояние, предшествовавшее неверной
(недопустимой) команде или некорректному вводу данных
R7.10
M
Система не должна позволять дублирование и повторный
(ошибочный) ввод однородной информации. Система должна
обеспечивать исключение дублирования и повторного ввода
информации, содержащейся в государственных базах данных и
информационных системах государственных органов.
R7.11
M
Система должна обеспечивать форматно-логический контроль
вводимых данных. Под форматно-логическим контролем вводимых
данных понимается контроль на формат и содержание вводимых
данных. При работе Системой должна быть предусмотрена защита
от ошибочных действий:
- выбор только доступных для пользователя (в соответствии с
правами доступа) функций;
- ввод только доступных для пользователя (в соответствии с
правами доступа) значений;
ввод данных только определенного формата (например,
невозможность ввода символьных данных в поле формата «Дата»
или «Число»).
Раздел VI. Технические требования
463
1.3 Требования к взаимодействию Системы
№
Тип
Требование
Требования к взаимодействию Системы
R8.
Общие требования к интероперабельности Системы
R8.1.
R8.1.1
M
Решения и приложения Системы должны соответствовать
стандартам интероперабельности, в том числе национальным
стандартам
и
принятым
международным
стандартам,
перечисленным в этой главе (и в этом документе).
R8.1.2
M
Компоненты Системы должны соответствовать национальным
инструментам семантики:
o Справочники и классификаторы
o Требования к сервисам справочников
o Требования к регистрам и сервисам регистров
Детали по требованиям для этих инструментов приведены в этом
разделе ниже (R8.3)
R8.1.3
I
Совместимость со стандартами
R8.2
R8.2.1
Некоторые из инструментов совместимости, описанных ниже,
находятся в процессе развития, и последние версии
предоставляются потенциальным поставщикам по запросу.
Основные стандарты приведены на сайте МЗРК (Приказ №75 от
10.02.2014 г, https://www.mzsr.gov.kz/node/319759)
M
Компоненты Системы должны быть совместимы не менее чем со
следующими стандартами МЗСР РК:
1) Стандартные требования к электронному паспорту здоровья
(требующий соблюдения EN 13940)
2) Стандартные требования к электронной медицинской записи
(требующий соблюдения EN 13940)
3) Стандартные требования к идентификации действующих сторон
здравоохранения, используемых в системах электронного
здравоохранения
4) Технические требования к взаимодействию (передаче
сообщений) с информационными системами электронного
здравоохранения
5) Регламент по обеспечению информационной безопасности
6) Стандартные требования к единому классификатору
лекарственных средств, изделий медицинского назначения и
медицинской техники
7) Стандартные требования к реализации и регулированию
Раздел VI. Технические требования
464
электронных направлений
8) Регламент взаимодействия заинтересованных сторон с целью
обеспечения интероперабельности информационных систем и
управления информационными потоками
9) Стандарт регулирования ведения рецептов в электронном
формате
10) Стандарт управления электронными процессами
диагностических исследований и лечебных процедур
11) Стандарт регулирования электронной профилактики
заболеваний
Указанные стандарты и нормативные документы доступны по
ссылке https://www.mzsr.gov.kz/taxonomy/term/619
R8.2.2
M
Компоненты Системы должны быть совместимы со следующими
международными стандартами:
a. EN 13940 (в части необходимости соответствия
стандартам ЭПЗ и ЭМЗ)
b. HL7 (ISO/HL7 27831) , HL7 (v2 или V3 или FHIR);
c. HL7 CDA R2 (ISO/ HL7 27932)
d. DICOM
R8.2.3
M
Система должна соответствовать требованиям стандартам по
информационной безопасности:
 СТ РК ИСО/МЭК 27001-2008 «Методы и средства
обеспечения безопасности системы управления
информационной безопасностью. Требования»;
 СТ РК ИСО/МЭК 27002-2009 «Информационная
технология. Средства обеспечения. Свод правил по
управлению защитой информации».
Требования
к
идентификаторов
справочниками
R8.3
и
совместимости
стандартными
с
национальными
классификаторами /
R8.3.1
M
Компоненты Системы должны поддерживать и соответствовать
требованиям к национальным идентификаторам:
- Идентификатор Пациентов
- Идентификатор организаций здравоохранения
- Идентификатор медработников
- Идентификатор медицинской техники
R8.3.2
M
Компоненты Системы должны поддерживать и соответствовать
требованиям, как минимум по следующим классификаторам и
справочникам:
1) Национальный классификатор лекарственных средств и
медицинских материалов (картированный к АТС- DDD )
2) Классификатор медицинских услуг (на основе МКБ-9, раздел по
Раздел VI. Технические требования
465
услугам и .д)
3) Классификатор результатов лабораторных исследований
4) Классификатор услуг и их стоимости
5) Классификатор диагнозов (МКБ-10)
6) Классификатор ПМСП (ICPC-2)
7) Картирование ICPC-2 и МКБ-10
8) SNOMED, (только для цели кодирования связи между Системой
и Репозиторием ЭПЗ)
9) Для управления диагностическими услугами улучшенная
система классификации, должна быть определена на более позднем
этапе;
10) Реализованная МЗ, национальная система КЗГ для
классификации пациентов (при оказании специализированной
помощи);
11) Классификатор регистров целевых групп пациентов
(Диспансерные группы);
12) Тарификатор медицинских услуг;
13) Специальностей здравоохранения;
14) Список должностей
Требования к совместимости / соответствию данных
R8.4
R8.4.1
M
Компоненты Системы должны обеспечивать связь между Системой
и Платформой, содержащей Репозиторий ЭПЗ, основываясь на
следующих данных:
- минимальный набор данных для ЭПЗ (приводится в Приложении
к Национальному стандарту ЭПЗ и Национальному стандарту
ЭМЗ)
- другие данные, не покрытые семантическими стандартами, но
необходимыми согласно НПА МЗСР РК, такие как Прикрепленные
специальные записи (документы, основанные на CDA)
R8.4.2
M
Система должна обеспечивать доступ к данным, хранящимся в
Репозитории ЭПЗ, в соответствии с 2 типами ЭПЗ: Полный ЭПЗ,
Краткий ЭПЗ. Подробности описаны в Национальном стандарте
ЭПЗ
R8.4.3
M
Данные передаются между Системой и Репозиторием ЭПЗ в
формате CDA
R8.4.4
M
Система должна предоставлять возможность передачи данных в
Репозиторий ЭПЗ на основе кодов ICPC-2, которые используются в
посещениях (и контактах в целом) и картированы к МКБ-10 для
целей сбора статистики. В ИС ЭМЗ (кроме систем ЭПЗ/ ПМСП)
специалисты используют для кодирования диагностики МКБ-10, и
картирование в обратном направлении не является обязательным,
лишь желательным.
Раздел VI. Технические требования
466
R8.4.5
I
Системы могут иметь дополнительные базы данных и репозитории,
необходимые для полного осуществления функциональности
(называемые ЭМЗ в контексте МЗСР РК), но они хранятся отдельно
от базы данных репозитория ЭПЗ. Содержание Репозитория ЭПЗ
строго следует регулированию национального стандарта ЭМЗ.
R8.4.6
M
Система должна быть достаточно открытой, чтобы быть способной
обеспечить интероперабельность с существующими ИС МЗСР РК,
приложениями и сервисами
Требования к информационному обмену
R8.5
R8.5.1
M
Система должна взаимодействовать с национальной системой ЭПЗ
в соответствии с Национальными стандартами ЭПЗ и ЭМЗ.
R8.5.2
M
Система должна поддерживать (как минимум) взаимодействие со
следующими наборами сервисов электронного здравоохранения:
 Сервисы репозитория ЭПЗ;
 Сервисы справочной информации;
 Сервисы регистрации и регистров;
 Сервисы Клинической Номенклатуры и классификации
данных;
 Сервисы безопасного обмена информацией и обмена
сообщениями;
 Сервисы идентификации и аутентификации;
Сервисы мониторинга и аудита для информационного
обмена.
R8.5.3
M
Система должна соответствовать как
профилям IHE:
a) Инфраструктурные профили IHE:
 ATNA;
R8.5.4
M

XDS.b;

PDQ;

PIX;
минимум следующим
Система должна обеспечить возможности
взаимодействия/интеграции с использованием как минимум
следующих протоколов и спецификаций:
a. Коммуникацию через SOAP (и сообщения SOAP с
приложением), REST, Message Transmission Optimization
Mechanism;
b. Поддержка стандартов и спецификаций веб-сервисов (WS-
Security, WS-Addressing, WS-Reliable Messaging, WScoordination, WS-Transaction, WS-Secure Conversation);
Раздел VI. Технические требования
467
c. Соответствовать стандартам XML (XML, XSL, ebXML, и
др.);
d. Поддерживать SSO и контроль доступа через SAML v2,
JWT;
e. Поддерживать общие стандарты, такие как HTTP, HTTPS,
TCP/IP, протоколы защищённых сокетов (SSL v3) и TLS;
f. Позволить использование WSDL, WADL;
g. X.509;
Цифровые подписи (ЭЦП НУЦ РК).
R8.5.5
M
Система должна поддерживать кодировку не менее чем UTF8.
R8.5.6
М
Система должна взаимодействовать с сервисами Платформы при
скорости канала 1 Мб/с и времени отклика не более 100 мс
Межсистемное взаимодействие
R8.6
R8.6.1
M
Взаимодействие с ИС МЗСР РК в части получения данных о
медицинских организациях, функциональных подразделениях и
сотрудниках медицинских организаций, а также общей справочной
информации, использующейся в ИС МЗСР РК
R8.6.2
M
Взаимодействие с ИС МЗСР РК с целью получения данных о
лицах, состоящих на диспансерном учете
R8.6.3
M
Взаимодействие с ИС МЗСР РК в части получения данных о
физических лицах и их прикреплении, смерти (причина смерти,
дата смерти)
R8.6.4
M
Взаимодействие с ИС МЗСР РК в части получения сведений о
пребывании пациента в стационаре (форма № 066/у)
R8.6.5
M
Система должна взаимодействовать с сервисами Платформы в
части:
 передачи/получения уведомлений и других сведений,
носящих информационный характер на шлюз «электронного
правительства»;
 отправки SMS-уведомлений и других видов рассылки
посредством
СМС-шлюза
системы
Мобильное
правительство;
 отправки электронных писем пациентам посредством
единой электронной почтовой системой;
 получения сведений о доверенностях из государственной
информационной
системы
Единая
нотариальная
информационная система;
 получения сведений по записям на прием к врачу;
Раздел VI. Технические требования

468
получения минимальной информации о сотруднике.
1.4 Сопутствующая информация о технологии отдельных вопросов
1.4.1 Использование национальных ресурсов электронного здравоохранения и
инструментов Платформы
Система должна быть способна использовать национальные ресурсы и
опубликованные сервисы электронного здравоохранения РК.
№
Тип
Требование
R9
Использование
национальных
ресурсов
электронного
здравоохранения и инструментов Платформы
R9.1
M
Система должна быть способна функционировать в соответствии с
общей архитектурой электронного здравоохранения (Рисунок 2)
R9.2
M
Система должна быть способна использовать функционал и вебсервисы, опубликованные на национальном уровне для взаимодействия
с ресурсами электронного здравоохранения.
R9.3
M
Система должна быть способной использовать репозиторий ЭПЗ,
национальные классификаторы и индексы (как минимум Главный
индекс пациента, индекс подразделений медицинских организаций,
индекс сотрудников, индекс зданий, адресный индекс, индекс
автотранспорта, индекс медицинской техники), аналитическое
хранилище и другие национальные ресурсы, необходимые для
интеграции «под-ключ» согласно национальным стандартам
(перечисленные в Приказе МЗ РК №75 от 10.02.2014 года)
R9.4
M
Система должна поддерживать локальные копии национальных
ресурсов и быть способной синхронизировать их на регулярной основе
(в соответствии с настраиваемым графиком) или онлайн. Система
должна содержать только информацию, касающуюся деятельности
медицинской организации. Например, Главный индекс пациентов
должен содержаться локально только для перечня пациентов,
обслуживающихся в данной организации.
1.4.2 Взаимодействие со сторонами, вовлеченными в процесс сертификации
№
Тип
R10
R10.1
I
Требование
Взаимодействие со сторонами,
вовлеченными в процесс
сертификации
Контракт, связанный с поставкой Платформы и национальных
ресурсов электронного здравоохранения проводится параллельно с
настоящим контрактом. Поставщику Системы будет предоставлен
доступ к национальным ресурсам электронного здравоохранения
только после того, как параллельный контракт будет успешно
реализован. В целях облегчения параллельной реализации необходимо
синхронизировать/координировать
совместные
действия.
Взаимодействие вовлеченных сторон приведено на Рисунке 3.
Раздел VI. Технические требования
R10.2
M
R10.3
M
R10.4
M
R10.5
M
R10.6
M
R10.7
M
R10.8
M
R10.9
I
R10.10
M
469
Действия, предпринимаемые Поставщиком описаны в 4 столбце
«Частные ИТ компании»
Поставщик системы должен взаимодействовать с Поставщиком
Платформы, Организацией и МЗСР РК в целях тестирования и
сертификации интероперабельности с национальными ресурсами и
сервисами.
Поставщик системы должен координировать взаимодействие
вовлеченных сторон в соответствии с Рисунком 3. Сертификация
заключается в проверке установленной системы на соответствие
требованиям R8.2. Покупатель уполномочит специальную комиссию,
которая совместно с Поставщиком Платформы и поставщиком данной
системы, проведут тесты, на соответствие требованиям по
интероперабельности в соответствии с национальными стандартами, в
том числе на способность корректного взаимодействия поставленной
системы, с национальными ресурсами предоставленными в рамках
платформы.
На этапе проектирования Системы (действие 4.4) Поставщик Системы
должен соблюдать требования «Регламентов разработки веб-сервисов»
и «Требования к взаимодействию с Репозиторием ЭПЗ»
предоставляемые поставщиком Платформы. Поставщик Системы
может запросить дополнительную информацию при необходимости
для разработки взаимодействия с ресурсами электронного
здравоохранения.
На этапе тестирования/сертификации (действие 4.6) поставщик
Системы должен соблюдать требования и стандарты электронного
здравоохранения R8.2
Поставщик обязан сертифицировать систему до приемки в
эксплуатацию.
В случае, возникновения обстоятельств, не позволяющих выполнить
требование R10.6 и происходящих не по вине Поставщика, Акты
приемки Системы могут быть подписаны без сертификации. При этом
поставщик Системы обязуется сертифицировать систему когда
появляются условия сертификации, без дополнительных затрат со
стороны Покупателя.
Система должна предоставлять возможность функционирования на
удаленной инфраструктуре и в облачной (виртуализированной)
операционной среде
Контракт, связанный с поставкой Платформы информатизации и
интероперабельности здравоохранения (далее - Платформа)
проводится параллельно с настоящим контрактом.
Поставщику Системы будет предоставлен доступ к национальным
ресурсам электронного здравоохранения только после того, как
параллельный контракт будет успешно реализован. В целях
облегчения
параллельной
реализации
необходимо
синхронизировать/координировать
совместные
действия
с
Раздел VI. Технические требования
470
поставщиком Платформы. В случае, возникновения обстоятельств, не
позволяющих выполнить требования по взаимодействию с
Платформой, ввиду задержки выполнения контракта по поставке
Платформы,
поставщик
Системы
обязуется
реализовать
взаимодействие, когда появятся условия, без дополнительных затрат
со стороны Покупателя.
Раздел VI. Технические требования
Рисунок . 3 Взаимодействие сторон, вовлеченных в процесс внедрения и
сертификации Системы. .
1.5 Требования к поставщикам
№
R11
Тип
Требование
Требования к поставщикам
471
Раздел VI. Технические требования
R11.1
M
R11.2
M
R11.3
M
R11.4
M
472
Поставщик будет поставлять свою собственную Систему
(компоненты и продукты, составляющие ее) или будет уполномочен
Разработчиком/владельцем этой Системы (компонентов и продуктов
составляющих ее) на обеспечение, разработку, установку,
сопровождение продукции в соответствии с настоящим тендером.
Поставщик будет проводить обучение в стране клиента, связанное с
использованием и администрированием Системы, а также для всех
разработанных и установленных продуктов. Языками обучения будет
государственный и русский. Детали по обучению приведены в R13.2
Поставщик должен иметь офис в стране Покупателя или иметь
партнера, зарегистрированного в качестве юридического лица в
стране Покупателя, имеющего официальный статус партнера
поставщика, или имеющего соглашение о консорциуме, связанном с
этим конкретным контрактом. Это необходимо во время реализации,
развертывания, обучения и гарантийного срока для гладкой и
надежной реализации контракта.
Поставщик должен иметь команду реализации проекта, состоящую не
менее чем из следующих специалистов (в случае необходимости, две
позиции могут быть приняты одним специалистом при условии, что
навыки будут доказаны, но не более чем 2 позиции на специалиста):
1) Бизнес-аналитик, имеющий опыт работы не менее 3 лет в ИТ
проектах электронного здравоохранения и опытом работы хотя бы в
одном аналогичном проекте;
2) Менеджер управления проекта (руководитель команды), имеющий
опыт работы не менее 3 лет в управлении проектами и опыт работы
более 1 года, где предлагаемое решение было реализовано и должен
иметь сертификат управления проектами (например, PMP или IPMI
не менее);
3) Специалист СУБД имеющий, не менее 3 лет опыта работы с СУБД;
4) Специалисты с опытов работы со стандартами не менее 2 лет: HL7,
DICOM, CDA (R2), IHE;
5) Дизайнер пользовательского интерфейса, имеющий опыт работы
не менее 3 лет;
6) Технический писатель, имеющий опыт работы не менее 2 лет;
7) Специалист по связям, имеющий опыт работы в данной области не
менее 3 лет общего опыта ИТ, с отличным владением английским,
русским и казахским языками;
8) Специалист по тестированию, имеющий не менее 3 лет опыта
тестирования ПО;
9) Специалист по обучению, имеющий не менее 3 лет опыт в
проведении обучения;
Все предлагаемые специалисты должны иметь высшее образование в
ИТ или взаимосвязанных областях, степень магистра
предпочтительна. Поставщик должен представит перечень
специалистов, с приложением резюме, сертификатов для
доказательства опыта работы и квалификации.
Раздел VI. Технические требования
R11.5
M
R11.6
M
R11.7
I
R11.8
M
R11.9
M
R11.10
M
R11.11
M
473
Поставщик должен представить все документы (патенты, лицензии,
свидетельства о государственной регистрации прав на объект
авторского права и т.п.) на Систему (для всех компонентов и
продуктов), демонстрирующие разрешение владельцев использовать
продукты для данного контракта или демонстрирующие владение
продуктами.
План - график оказания услуг должен быть согласован с
уполномоченной организацией Покупателя и подписан Покупателем
в течение 20 (двадцати) рабочих дней после подписания договора.
Поставщик должен своевременно оказывать услуги согласно
утвержденному план-графику.
В случае участия зарубежных компаний, консорциум является
наиболее вероятной подходящей формой участия в тендере (хотя и не
обязательной), потому что некоторые из требований предполагают
знания и навыки, которыми международные поставщики могут не
обладать - опыт работы в стране.
Производители ПО должны иметь как минимум один сертификат из
следюущего перечня: Capability Maturity Model Integration (CMMI),
ISO 9000 series, СТ РК ISO 9001:2009 или эквивалент по
менеджменту качества (Участник торгов должен представить копии
сертификатов соответствия выданных уполномоченным органом)
Поставщик должен обеспечить обслуживание и техническую и
гарантийную поддержку, включая предоставление новых версий
продуктов в соответствии с R13.3 и R13.4.
Поставщик должен подготовить соответствующие руководства для
всех компонентов Системы на английском, казахском и русском
языках.
Поставщик должен иметь доказанный опыт работы со стандартами,
используемыми в настоящем документе: HL7 (v2, V3, FHIR), CDA
(R2), IHE.
Раздел VI. Технические требования
474
C. ТЕХНИЧЕСКИЕ СПЕЦИФИКАЦИИ
2.1. Общие технические требования к Системе
№
R12
Тип
Требование
Общие технические требования к Системе
R12.1
М
Система должна иметь централизованную архитектуру и быть
разработанной в виде веб-приложения, в котором клиентом
выступает браузер, а сервером – веб-сервер.
R12.2
М
Доступ к клиентскому приложению должен осуществляться
посредством любого из следующих Интернет-браузеров: MS Internet
Explorer, Google Chrome, Opera, Safari, Mozilla Firefox
R12.3
M
Серверная часть Системы должна поддерживать работу как
минимум в операционных системах семейства Windows.
R12.4
M
Клиентская часть Системы должна поддерживать работу как
минимум в операционных системах Windows (2008/VISTA/7/8)
(x86/x64)
R12.5
M
Для сохранения информации в Системе должна использоваться
реляционная база данных.
R12.6
M
База данных Системы должна поддерживать стандартный SQL,
совместимый со стандартом ANSI/ISO/IEC 9075-1992
R12.7
M
Поставщик обязан обеспечить обслуживание и техническую
поддержку, включая предоставление новых версий продуктов до
истечения срока гарантийного обслуживания
R12.8
M
Система должна предоставлять возможность аутентификации с
использование технологии Single Sign On
2.2 Спецификация услуг
№
R13
R13.1
R13.1.1
Тип
M
Требование
Спецификация услуг
Требования к наследованию данных и функционала.
В случае поставки и внедрения Системы отличной от
эксплуатируемой заказчиком Исполнитель осуществляет полный
комплекс необходимых работ по наследованию данных и
функционала, используемых Заказчиком модулей информационной
системы с подключением к Системе используемых Заказчиком
программных и технических средств автоматизации, медицинского и
Раздел VI. Технические требования
R13.1.2
M
R13.2
R13.2.1
M
475
лабораторного оборудования.
Все затраты, связанные с обеспечением наследования данных и
функционала несет Исполнитель.
Обучение и учебные материалы
Поставщик должен подготовить учебный план для обучения
следующих групп:
a) пользователи системы;
b) администраторы системы;
c) разработчики,
d) администраторы баз данных.
R13.2.2
M
R13.2.3
M
R13.2.4
M
R13.2.5
M
R13.2.6
M
R13.2.7
M
R13.2.8
M
Учебный план и учебные материалы по каждой группе должны быть
согласованы с Покупателем до начала обучения.
Поставщик должен обеспечить оборудование, презентационные
материалы и пособия, необходимые для обучения
Поставщик Системы должен представить учебные материалы в
форме руководств, учебных книг и презентаций, баз знаний на
государственном и русском языках.
Поставщик должен провести обучение как минимум 80 часов для
каждой группы администраторов системы, разработчиков,
администраторов баз данных и 20 часов для пользователей каждой
медицинской организации, в которой проводится внедрение
Системы. Количество часов может быть увеличено и должно быть
достаточно для передачи знаний и навыков.
Поставщик
должен
проводить
отдельное
обучение
для
пользователей и администраторов системы, разработчиков,
администраторов баз данных. Индикативное число обучаемых
определяется путем умножения на 2 общего количества
автоматизированных рабочих мест из Приложения 7. Место
обучения – юридический адрес медицинской организации –
бенефициара . Группы обучающихся должны включать не более 10
человек
Учебный план для группы (а) - пользователи системы - должен
содержать детальное разъяснение автоматизированных бизнес
процессов, использование всех компонентов системы, подробное
описание функций и взаимодействий между различными
пользователями и ролями; отчётность и другая необходимая
информация. Обучение также будет содержать практические
тренинги для понимания материала.
Учебный план для группы (b) - администраторы системы - должен
содержать описание инструментов администрирования компонентов
системы, включая важные вопросы сопровождения системы, и
аспекты технической поддержки.
Поставщик должен провести для группы (c) разработчики один
вводный курс и один курс повышения квалификации по
Раздел VI. Технические требования
R13.2.9
M
R13.2.10
M
R13.2.11
M
R13.2.12
M
R13.2.13
I
R13.3.
R13.3.1
M
R13.3.2
M
R13.4.
R13.4.1
M
R13.4.2
M
476
предоставляемым
средствам
разработки
и
компонентам,
предусмотренных в рамках данного контракта.
Поставщик должен провести для группы (d) администраторы баз
данных один вводный курс и один курс повышения квалификации
по предоставляемой СУБД.
Обучение для групп (a) - (d) должно проводиться на русском языке
или на госсударственном языке по требованиям Покупателя.
Все тренинги проводятся тренерами в Астане или в другом месте,
указанном Покупателем.
Для всех проведенных тренингов, Поставщик должен провести
соответствующее тестирование и выдавать сертификаты.
Вышеуказанное количество и продолжительность обучения
являются минимальными требованиями. Поставщик по запросу
Покупателя может увеличить эти величины (в часах) для достижения
адекватного уровня навыков для персонала без дополнительных
затрат со стороны Покупателя. Во время этапа подготовки проекта
точное число часов, групп и содержания курсов будут согласованы с
Поставщиком.
Служба поддержки пользователей
Поставщик должен организовать службу поддержки пользователей
для консультирования по вопросам, возникающим в процессе
эксплуатации, на все время внедрения и обеспечения гарантийного
обслуживания.
Техническая поддержка Системы и её пользователей должна
осуществляться Поставщиком в режиме 24 часа в сутки, 7 дней в
неделю, в течение 3 лет, начиная сразу после согласования
Покупателем Акта приемки.
Гарантийный сервис
Поставщик Системы будет обеспечивать гарантийное обслуживание
Покупателя в течение 3 лет, начиная сразу после согласования
Покупателем Акта приемки.
Поставщик должен обеспечить разрешение запросов:
a) для критичных проблем, касающихся работоспособности
Системы и ведущих к повреждению данных, проблема
должна быть решена не более чем за 2 часов;
b) для не критичных проблем не более 2 дней.
R13.4.3
M
Гарантийное обслуживание включает в себя, но не ограничивается,
следующими категориями услуг:
- Исправление ошибок в Системе;
- Помощь Организации в правильном исправлении всех
проблем с данными, возникающими в результате ошибочной
функции приложений;
- Обеспечение технической поддержки в настройке
приложения или изменения параметров по умолчанию;
Раздел VI. Технические требования
R13.4.4
M
R13.4.5
M
R13.4.6
M
R13.4.7
M
477
Оказание
необходимой
технической
помощи
квалифицированному персоналу и переподготовка, если
выявлено, что они не могут решить все проблемы после
полученной подготовки;
Формы вмешательства могут быть одним из следующих наиболее
подходящих с точки зрения качества и эффективности:
○
Телефонные звонки;
○
По электронной почте;
○
Skype или другие мессенджеры с поддержкой видео;
○
Удаленный доступ к пользователю;
○
Работа на месте.
Поставщик должен обеспечить в течении гарантийного срока группу
консультантов, доступных в стране Покупателя в том числе одного
менеджера и как минимум одного технического специалиста, и
предоставить всех необходимых специалистов на расстоянии для
дистанционной помощи (по мере необходимости).
Суммарное время простоя Системы по причинам, связанным с её
работоспособностью не должно превышать 24 часов в год.
Время однократного простоя Системы по причинам, связанным с её
работоспособностью не должно превышать 2 часов.
2.3. Требования к документации
№
R14
R14.1
Тип
M
Требование
Требования к документации
Поставщику
необходимо
предоставить
документов:
● Программа и методика испытаний;
следующий
пакет
● Формуляр
(основные характеристики, комплектность и
сведения об эксплуатации депонируемого программного
продукта);
● Описание наиболее распространенных ошибок и способов их
устранения;
● Описание структуры базы данных;
● Руководство по установке программного обеспечения;
● Руководство администратора;
● Руководство пользователя.
R14.2
M
Языками документов должны быть как минимум государственный и
русский.
Раздел VI. Технические требования
R14.3
M
R14.4
M
478
Поставщик должен предоставить 5 комплектов документации в
бумажном и электронном виде на английском, русском и казахском
языках.
Электронные версии должны поддерживать возможность
контекстового поиска.
Поставщик должен подготовить информационную систему и
нормативно-методическую документацию к проведению аттестации
на соответствие требованиям информационной безопасности
согласно со статьей 5 Закона Республики Казахстан от 11 января
2007 года «Об информатизации» и Постановлением Правительства
Республики Казахстан от 30 декабря 2009 года № 2280 «Об
утверждении Правил проведения аттестации государственных
информационных систем и негосударственных информационных
систем, интегрируемых с государственными информационными
системами, на соответствие их требованиям информационной
безопасности и принятым на территории Республики Казахстан
стандартам» и к вводу в эксплуатацию в соответствии со статьей 17
Закона Республики Казахстан от 11 января 2007 года «Об
информатизации».
Раздел VI. Технические требования
479
D. ТЕСТИРОВАНИЕ И ТРЕБОВАНИЯ ПО ГАРАНТИИ КАЧЕСТВА
3.1. Тестирование системы и требования гарантии качества
№
R15
R15.1
R15.1.1
Тип
R15.1.2
M
R15.1.3
I
Качество тестов является одним из критериев для технической
оценки. Список тестов будет включать в себя тесты для каждого
модуля и тесты для Системы в целом.
R15.1.4
M
R15.1.5
М
R15.1.6
М
R15.1.7
М
R15.1.8
М
R15.1.9
М
R15.1.10
М
Поставщик Системы проведет поэтапные детальные испытания, в
том числе тесты производительности, времени отклика,
пропускной способности, Системы совместно с организацией,
уполномоченной Покупателем, согласно тестам предоставленным
Поставщиком.
Поставщик должен провести демонстрацию Системы с участием
представителей Покупателя и организацией, уполномоченной
Покупателем согласно сценарию испытаний Системы на любом
этапе контракта.
Поставщик должен оформить результаты демонстрации в виде
Протокола о проведении демонстрации по форме, согласованной с
Покупателем. Протокол должен быть подписан всеми участниками
демонстрации.
Место проведение демонстрации согласовываются с Покупателем
и организацией уполномоченной Покупателем.
Поставщик должен устранять замечания, полученные в ходе
проведения демонстраций, и проводить повторные демонстрации
до получения протокола об успешном проведении демонстрации.
Сроки устранения замечаний согласовываются с Покупателем.
Тестирование должно осуществляться в соответствии с одним из
стандартов IEEE 829/1009, BS 7925, ISO/AS 9100 и разработанным
документом «Программа и методика испытаний» СТ РК 1089-2002.
Поставщик должен протестировать Систему в соответствии с
Руководством по обеспечению доступности веб-контента (Web
Content Accessibility Guidelines)
2.0. Поставщик должен
представить подробную информацию о результатах тестировании.
Поставщик должен протестировать Систему по безопасности в
соответствии с Открытым проектом обеспечения безопасности
M
Требование
Тестирование системы и требования гарантии качества
Предпусковые работы
Поставщик
Системы
должен
выполнять
стандартные
установочные тесты для проверки корректной установки Системы.
Поставщик должен предложит в рамках технического
предложения список тестов, условий испытаний, критериев успеха
и другого для испытаний Системы.
Раздел VI. Технические требования
R15.1.11
М
R15.2
R15.2.1
M
R15.2.2
M
480
веб-приложений (Open Web Application Security Project) Топ 10
уязвимости. Поставщик должен представить подробную
информацию о результатах тестировании.
Поставщик должен согласовать с Покупателем сценарий
тестирования и предоставить отчёт по результату каждого
тестирования.
Приемка в эксплуатацию
Акт
приемки
Системы
подписывается
на
основании
бесперебойной работы при нормальных условиях эксплуатации
для Системы в течении 3 месяцев. В случае выявления ошибок
функционирования в данный период Поставщик должен внести
необходимые изменения и провести повторную эксплуатацию
Системы в течении 3 месяцев. Под ошибками функционирования
понимаются критические ошибки, которые не позволяют
эксплуатировать Систему
Поставщик должен начать необходимую работу для устранения
дефектов или повреждений в течение 10 рабочих дней для
некритичных ошибок. Для критических ошибок поставщик
должен начать работу, необходимую для устранения дефектов или
повреждений в течение 3 рабочих дней, обеспечить фиксацию
времени и отчет о фиксации хода каждый час в течение
оперативного, а также гарантийного срока.
Критические ошибки: система не работает или работает не
стабильно. Важная функциональная составляющая не работает или
недоступна. Потеря данных или прерывание основного потока
процесса. Компонент системы непригоден из-за сбоя или
неправильной функциональности. Пользователи не могут
выполнять любую работу.
3.2. Требования к обеспечению контроля со стороны Покупателя
№
Тип
Требование
Требования к обеспечению контроля со стороны Покупателя
R16
R16.1
М
Поставщик должен с периодичностью, определенной в планграфике, предоставлять Покупателю отчет о проделанной работе
за истекший период.
R16.2
М
Отчет должен содержать информацию о выполненных работах
Поставщика за отчетный период, в соответствии с утвержденным
план-графиком, включая услуги по гарантийной поддержке, по
СТП с приложением всей утвержденной в процессе реализации
договора за отчетный период документации, включая
официальную переписку, в бумажном и электронном виде (в
Раздел VI. Технические требования
481
формате не менее pdf).
R16.3
М
Отчет должен быть согласован с организацией, уполномоченной
Покупателем.
R16.4
М
Покупатель может в любой момент исполнения договора
проводить контроль исполнения Поставщиком мероприятий и
качества услуг по договору.
Раздел VI. Технические требования
482
E. ГРАФИК РЕАЛИЗАЦИИ
График реализации в табличной форме
Закупка лота 10
№
пози
ции
10.
Подсистема/ деталь
Медицинская
информационная
система для учета доноров,
реципиентов и лиц, ожидающих
трансплантацию
№ таблицы
конфигурации
участок /
код участка
Поставка
(заявитель
должен
указать в
Предварител
ьном планепроекте)
Установка
(недель с
даты
подписания)
Приемка
(недель с
даты
подписания)
41
54
Ориентир
для
неустойки
да
Раздел VI. Технические требования
483
Инвентаризационная таблица системы (Затраты на поставку и инсталляцию)
Система, подсистема и номер лота: лот 10
Компонент
Компонент
No.
1.
Медицинская информационная система для учета
доноров,
реципиентов
и
лиц,
ожидающих
трансплантацию
Соответствующая
техническая
спецификация
No.
Дополнительная
информация по месту
поставки (например:
здание, этаж, отдел, и т.д.)
Количество
1
Раздел VI. Технические требования
484
Таблица мест поставки
Система, подсистема или номер лота: закупка всей Системы
Место поставки
Город/Регион
Адрес
г.Астана
Алматинский район, улица
Силети, 30
№ места
поставки
1.
Республиканский
координационный центр по
трансплантации
Ссылка на
чертеж No.
(если
требуется)
Раздел VI. Технические требования
485
Праздники и прочие не рабочие дни
Месяц
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
Раздел VI. Технические требования
486
G. КОНТРОЛЬНЫЙ СПИСОК ТЕХНИЧЕСКОГО СООТВЕТСТВИЯ
Примечание для участников: Следующий контрольный список поможет
участникам торгов организовать и последовательно представить свои технические
предложения. Для каждого из следующих технических требований, Участник торгов
должен описать, как его техническое предложение реагирует на каждое требование.
Кроме того, Участник торгов должен представить перекрестные ссылки на
соответствующую вспомогательную информацию, если таковая имеется.
Перекрестные ссылки должны определить соответствующий документ (ы), номер
страницы (ы), и пункт (ы). Контрольный список технического соответствия не
заменяет оставшуюся часть Технических требований (или любой другой части
тендерной документации). Если требование не упоминается в Перечне, это не
освобождает Участника от ответственности в том числе подтверждения соблюдения
этого требования. Ответов состоящих из одного или двух слов (например, "Да", "Нет",
"Будет соответствовать" и т.д.), как правило, не достаточно для подтверждения
технического соответствия техническим требованиям.
Раздел VI. Технические требования
487
Контрольный список технического соответствия
Номер
Описание
Обязательное
(M)/
Преимуществен
ное (P)
R1
Общие бизнес-требования к Системе
R1.1
Механизм лицензирования для Системы в M
рамках данного контракта предоставляет право
использовать все ее модули и составные части
для количества пользователей, достаточного
для
полноценного
функционирования
медицинской организации (размер организации
можно оценить из описания в Приложении 7), в
течение
неограниченного
времени,
неограниченного количества серверов, снимая
все прочие возможные ограничения. Не
Номер пункта
Расходы,
необходимые для
обеспечения
технического
соответствия:
Перекр
естные
ссылки
на
вспомо
гатель
ную
инфор
мацию
по
стоимо
сти
обеспе
чения
технич
еского
соотве
тствия
Раздел VI. Технические требования
допускаются ежегодные лицензионные сборы;
полная стоимость лицензии включает в себя
все расходы на лицензирование Системы.
R1.2
В рамках данного Контракта должна быть M
обеспечена интероперабельность Системы с
национальной
системой
электронного
здравоохранения согласно требованиям R7.
Общая схема взаимодействия с национальной
системой
электронного
здравоохранения
представлена на Рисунке 1.
R1.R1.3
Обобщенная
архитектура
комплексной М
информационной системы здравоохранения,
которой должна соответствовать Система,
представлена на рисунке 2
R1.4
Система должна представлять собой веб- М
приложение
R1.5
Система должна иметь способность тонкой М
настройки, чтобы обеспечить конфигурацию
под потребности конкретной Организации без
необходимости новой разработки (или включая
малую доработку)
R1.6
Поставщик в рамках данного Контракта М
должен
обеспечить
интероперабельность
Системы с Национальными инструментами
ЭПЗ (Репозиторий ЭПЗ, Национальные
классификаторы
и
идентификаторы,
аналитическое хранилище, ЭПЗ-веб-сервисы) в
488
Раздел VI. Технические требования
соответствии с R8
R1.7
Система
должна
обеспечивать М
конфиденциальность персональных данных в
процессе сохранения и передачи: шифрование
конфиденциальных данных в базе данных,
шифрование данных при передаче через
каналы, использование безопасных протоколов
передачи и т.д.
R1.8
Система должна обеспечивать возможность М
использования электронно-цифровой подписи
для
подписания
и
аутентификации
электронных документов, файлов и частей
документов. Необходимость использования
электронно-цифровой подписи должна быть
конфигурируемой на уровне системного
администратора.
R1.9
Система
должна
быть
полностью М
работоспособной и сдана Покупателю «под
ключ» в соответствии с R15.2.
R1.10
Поставщик должен обеспечить не менее чем, М
но
не
ограничиваясь,
следующее:
конфигурацию, развертывание, установку,
тестирование Системы. Поставщик должен
обеспечить
обучение
пользователей,
администраторов (и другого персонала при
необходимости).
R1.11
Поставщик должен участвовать в процессе М
489
Раздел VI. Технические требования
сертификации
Системы
совместно
с
Поставщиком Платформы с целью проверки и
сертификации
интероперабельности
с
национальными ресурсами и инструментами
ЭПЗ, в процедурах проведения аттестации и
испытаний Системы
R1.12
Поставщик должен обеспечить гарантийное М
обслуживание Системы в течение 3 лет со дня
передачи системы в эксплуатацию Покупателю
в соответствии с R13.4.
R1.13
В
случае,
если
для
полноценного М
функционирования Системы «под ключ»
необходимо
наличие
дополнительного
лицензионного программного обеспечения,
Поставщик обязан обеспечить наличие всех
лицензий за свой счет и их передачу в
собственность Покупателя в рамках данного
Контракта.
R1.14
Минимальные требования для каждого модуля М
должны соответствовать требованиям раздела
R2
R1.15
Система
должна
иметь
возможности D
интеграции со средами разработки (IDE), как
минимум для Java и Net Framework. Система
должна иметь в комплекте средства разработки
(SDK), включающий в себя: документацию,
примеры кода как минимум для Java и Net
Framework, для конфигурирования функции
490
Раздел VI. Технические требования
Системы.
Должна
быть
возможность
расширения функциональности Системы с
использованием средств разработки (SDK),
входящих в состав Системы.
R1.16
Механизм лицензирования для Системы в М
рамках данного контракта не должен
ограничивать изменения, вносимые с помощью
средств разработки (SDK), входящих в состав
Системы. Внесение изменений с помощью
средств разработки (SDK), входящих в состав
Системы, не должно влиять на условия
гарантийного
обслуживания
Системы.
Внесение изменений в Систему специалистами
Заказчика допускается после сдачи Системы в
эксплуатацию.
R1.17
Поставщик должен обеспечить обслуживание и М
техническую
поддержку,
включая
предоставление новых версий продуктов
(согласно R13.3).
R1.18
Время отклика сервисов и компонентов М
Системы должно быть не более 3-5 секунд, для
не менее 80% случаев ввода данных или
запросов на просмотр данных (при скорости
канала 1 Мб/с и времени отклика не более 100
мс).
R1.19
Поставщик
должен
документировать
и М
передать
в
электронном
виде
конфигурационные файлы, и исходный код,
491
Раздел VI. Технические требования
492
компонентов Системы, разработанные в рамках
данного контракта.
R1.20
Система должна иметь тонкий клиент, для М
взаимодействия с оборудованием допускается
использование толстого клиента.
R2
Требования к автоматизированным процессам
R2.1
Модуль «Администрирование»
R2.1.1
Настройка учетных записей пользователей М
Системы. Данный процесс включает, как
минимум:
R2.1.1.1
Создание учетных записей пользователей
R2.1.1.2
Редактирование
пользователей
R2.1.1.3
Удаление учетных записей пользователей
R2.1.2
Настройка прав пользователей Системы и М
четкого разграничения зон ответственности по
региональному и административному признаку.
Данный процесс включает, как минимум:
R2.1.2.1
Персонифицированное
учетных
M
записей M
M
назначение M
Раздел VI. Технические требования
493
пользователю прав доступа
R2.1.2.2
Разграничение прав пользователей системы по M
ролям, группам и уровню доступа с учётом
иерархии объектов и принадлежности к
организационной структуре
R2.1.2.3
Редактирование прав доступа пользователей
M
R2.1.2.4
Удаление прав доступа пользователей
M
R2.1.3
Конфигурирование
критериев
для М
автоматического
подбора
подходящего
реципиента из «листа ожидания». Данный
процесс включает, как минимум:
R2.1.3.1
Редактирование
(добавление/удаление) M
критериев для автоматического подбора
подходящего реципиента из «листа ожидания»
R2.1.3.2
Редактирование
весовых
коэффициентов M
(баллов) критериев для автоматического
подбора подходящего реципиента из «листа
ожидания»
R2.1.4
Конфигурирование регистрационных форм М
реципиентов/доноров.
Данный
процесс
включает, как минимум:
R2.1.4.1
Редактирование (добавление/удаление полей, M
Раздел VI. Технические требования
редактирование
существующих
полей)
входных
форм
для
регистрации
реципиентов/доноров/лиц, нуждающихся в
трансплантации
R2.1.4.2
Добавление/удаление входных форм для M
регистрации
реципиентов/доноров/лиц,
нуждающихся в трансплантации
R2.1.4.3
Использование
при
создании
и M
редактировании
входных
форм
для
регистрации
реципиентов/доноров/лиц,
нуждающихся в трансплантации следующих
функций:

изменение настроек шрифта (стиль,
размер, жирный, подчеркнутый, курсив и т.д.)

изменение цвета шрифта

создание сложных входных форм с
подразделами

возможность использования любого
справочника в системе для заполнения поля во
входной формы

возможность использования любой
сущности в базе данных для заполнения поля
во входной формы

возможность использования любой
выборки из базы данных для заполнения поля
во входной формы
494
Раздел VI. Технические требования
495

формирование
правил
заполнения
входной формы: только из списка, из списка с
возможностью дополнения, в свободной
форме, из выборки и т.д.

создание
новых
справочников,
используемых при заполнении входной формы
R2.1.5
Импорт данных в Систему из файлов формата М
xls, xml.
R2.1.6
Ведение системных журналов. Данный процесс M
включает, как минимум:
R2.1.7
Журнал создания, изменения
записей в базе данных
R2.1.8
Журнал истории входов пользователей
M
R2.1.9
Журнал получения отчетных форм
M
R2.1.10
Журнал просмотра данных
M
R2.1.11
Журнал
обработки
изменение, удаление)
R2.1.12
Журнал действий по архивированию
R2.1.13
Журнал
ошибок
и
и
данных
аварийных
удаления M
(создание, M
M
остановок M
Раздел VI. Технические требования
496
программы
R2.1.14
Журнал
синхронизации
с
внешними M
(национальными)
справочниками,
классификаторами, индексами и регистрами
R2.1.15
Архивирование журнала
R2.2
Модуль «Регистрация лица, нуждающегося в
трансплантации»
R2.2.1
Регистрация в «Листе ожидания» лица, М
нуждающегося в трансплантации по форме
согласно Приложении 1-1, 1-2, 1-3 к настоящей
технической
спецификации. Возможность
регистрации одного больного в нескольких
«Листах ожидания». Данный процесс включает,
как минимум:
R2.2.1.1
Регистрация в «Листе ожидания» лица, M
нуждающегося в трансплантации сердца по
форме согласно Приложении 1-1 к настоящей
технической спецификации
R2.2.1.2
Регистрация в «Листе ожидания» лица, M
нуждающегося в трансплантации печени по
форме согласно Приложении 1-2 к настоящей
технической спецификации
R2.2.1.3
Регистрация
в
«Листе
M
ожидания»
лица, M
Раздел VI. Технические требования
нуждающегося в трансплантации почек по
форме согласно Приложении 1-3 к настоящей
технической спецификации
R2.2.1.4
Регистрация одного больного в нескольких M
«Листах ожидания» (при необходимости)
R2.2.1.5
Возможность печати информации о пациенте M
согласно Приложении 1-1, 1-2, 1-3 к настоящей
технической спецификации.
R2.2.1.6
Возможность экспорта информации о пациенте M
согласно Приложении 1-1, 1-2, 1-3 к настоящей
технической спецификации в документы
формата pdf, xls, doc.
R2.2.2
Автоматическое получение информации о M
необходимости
регистрации в «Листе
ожидания»
лица,
нуждающегося
в
трансплантации, на основании информации из
ИС МЗСР РК (данный функционал должен
быть реализован по мере готовности
необходимого
для
взаимодействия
функционала на стороне вышеуказанных ИС).
Данный процесс включает, как минимум:
R2.2.2.1
Автоматическое получение информации от ИС M
МЗСР РК о необходимости регистрации
пациента в «Листе ожидания»
497
Раздел VI. Технические требования
R2.2.2.2
Регистрация пациента в «Листе ожидания» M
согласно Приложении 1-1, 1-2, 1-3 к настоящей
технической спецификации на основании
информации ИС МЗСР РК
R2.2.2.3
Регистрация одного больного в нескольких M
«Листах ожидания» (при необходимости).
R2.2.2.4
Возможность печати информации о пациенте M
согласно Приложении 1-1, 1-2, 1-3 к настоящей
технической спецификации.
R2.2.2.5
Возможность экспорта информации о пациенте M
согласно Приложении 1-1, 1-2, 1-3 к настоящей
технической спецификации в документы
формата pdf, xls, doc.
R2.2.3
Ведение информации о текущем состоянии М
лица,
нуждающегося
в
трансплантации
(улучшение
или
ухудшение
течения
заболевания в связи с прогрессированием,
развитием
осложнений,
присоединением
другого заболевания и другого). Данный
процесс включает, как минимум:
R2.2.3.1
Поиск пациента по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку.
R2.2.3.2
Ведение информации о текущем состоянии M
498
Раздел VI. Технические требования
499
пациента: улучшении или ухудшении течения
заболевания,
развитие
осложнений,
присоединение другого заболевания и другом.
R2.2.3.3
Хранение в Системе
состояния пациента
R2.2.3.4
Просмотр
пациента
R2.2.3.5
Возможность печати информации о состоянии M
пациента.
R2.2.3.6
Возможность печати
состояния пациента.
R2.2.3.7
Возможность
экспорта
информации
о M
состоянии пациента в документы формата pdf,
xls, doc.
R2.2.3.8
Возможность экспорта истории изменения M
состояния пациента в документы формата pdf,
xls, doc.
R2.2.4
Мониторинг «Листа ожидания».
процесс включает, как минимум:
R2.2.4.1
Поиск пациента по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
истории
истории
изменения M
изменения
состояния M
истории
изменения M
Данный М
Раздел VI. Технические требования
другому признаку.
R2.2.4.2
Просмотр «Листа ожидания» (в том числе M
выдача ежедневной информации в разрезе
регионов о количестве пациентов взрослого и
детского возраста, количестве выбывших из
«Листа ожидания» с указанием причин,
количестве новых случаев).
R2.2.4.3
Сортировка и фильтрация «Листа ожидания» M
по ФИО пациента, возрасту пациента, полу
пациента, дате внесения в «Лист ожидания»,
региону,
медицинской
организации,
органу/ткани, в трансплантации которой
нуждается пациент и другому признаку.
R2.2.4.4
Возможность печати «Листа ожидания» (в том M
числе
отфильтрованного
и/или
отсортированного).
R2.2.4.5
Возможность экспорта «Листа ожидания» (в M
том
числе
отфильтрованного
и/или
отсортированного) в документы формата pdf,
xls, doc.
R2.3
Модуль «Стационарный трансплантационный
координатор»
R2.3.1
Регистрация возможного донора по форме М
согласно Приложения 2 к настоящей
500
Раздел VI. Технические требования
501
технической спецификации. Данный процесс
включает, как минимум:
R2.3.1.1
Регистрация возможного донора согласно M
Приложения 2 к настоящей технической
спецификации
R2.3.1.2
Ведение
информации
о
обследования возможного донора
R2.3.1.3
Просмотр
ранее
зарегистрированных M
возможных
доноров
с
возможностью
сортировки и фильтрации по возрасту
пациента, полу пациента, диагнозу, дате
поступления и другому признаку.
R2.3.1.4
Возможность печати информации о возможном M
доноре.
R2.3.1.5
Возможность
экспорта
информации
о M
возможном доноре в документы формата pdf,
xls, doc.
R2.3.2
Регистрация потенциального донора по форме М
согласно Приложения 2 к настоящей
технической спецификации. Данный процесс
включает, как минимум:
R2.3.2.1
Регистрация потенциального донора согласно М
Приложения 2 к настоящей технической
результатах M
Раздел VI. Технические требования
502
спецификации
R2.3.2.2
Ведение
информации
о
результатах М
обследования потенциального донора
R2.3.2.3
Просмотр
ранее
зарегистрированных М
потенциальных доноров с возможностью
сортировки и фильтрации по возрасту
пациента, полу пациента, дате поступления в
ОРИТ,
по
органу/ткани,
которые
предполагается изъять и другому признаку.
R2.3.2.4
Возможность формирования сводных отчетных М
форм по зарегистрированным потенциальным
донорам за определенный период
R2.3.2.5
Возможность печати сводных отчетных форм M
по
зарегистрированным
потенциальным
донорам за определенный период
R2.3.2.6
Возможность
печати
потенциальном доноре
R2.3.2.7
Возможность экспорта сводных отчетных форм М
по
зарегистрированным
потенциальным
донорам за определенный период в документы
формата pdf, xls, doc
R2.3.2.8
Возможность
экспорта
информации
о М
потенциальном доноре в документы формата
информации
о
Раздел VI. Технические требования
503
pdf, xls, doc
R2.3.3
Регистрация актуального донора по форме М
согласно Приложения 2 к настоящей
технической спецификации. Данный процесс
включает, как минимум:
R2.3.3.1
Регистрация актуального донора согласно М
Приложения 2 к настоящей технической
спецификации
R2.3.3.2
Ведение
информации
о
результатах М
обследования актуального донора
R2.3.3.3
Просмотр
ранее
зарегистрированных М
актуальных
доноров
с
возможностью
сортировки и фильтрации по ФИО пациента,
возрасту пациента, полу пациента, по
органу/ткани, которые предполагается изъять и
другому признаку.
R2.3.3.4
Формирование сводных отчетных форм по М
зарегистрированным актуальным донорам за
определенный период
R2.3.3.5
Возможность печати сводных отчетных форм М
по зарегистрированным актуальным донорам за
определенный период
R2.3.3.6
Возможность
печати
информации
об М
Раздел VI. Технические требования
504
актуальном доноре
R2.3.3.7
Возможность экспорта сводных отчетных форм М
по зарегистрированным актуальным донорам в
документы формата pdf, xls, doc
R2.3.3.8
Возможность
экспорта
информации
об М
актуальном доноре в документы формата pdf,
xls, doc
R2.3.4
Ведение информации о текущем объективном М
статусе донора (возможного, потенциального,
актуального), Данный процесс включает, как
минимум:
R2.3.4.1
Ведение информации о текущем объективном M
статусе донора
R2.3.4.2
Просмотр истории изменения объективного M
статуса донора
R2.3.4.3
Возможность
печати
информации
объективном статусе донора
R2.3.4.4
Возможность печати истории
объективного статуса донора
R2.3.4.5
Возможность
экспорта
информации
об M
объективном статусе донора в документы
об M
изменения M
Раздел VI. Технические требования
формата pdf, xls, doc.
R2.3.4.6
Возможность экспорта истории изменения M
объективного статуса донора в документы
формата pdf, xls, doc.
R2.4
Модуль «Лабораторные исследования»
R2.4.1
Ведение
результатов
выполненных М
исследований, включая, но, не ограничиваясь
информацией о результатах исследования
иммунологического
типирования
тканей
высокого, среднего и низкого разрешения лиц,
рекомендованных
к
трансплантации
и
потенциальных доноров (форма №410-10/у),
информацией о результатах индивидуальной
пробы
на
совместимость
«Кросс-матч»
потенциальных
доноров
и
лиц,
рекомендованных к трансплантации (форма
№410-11/у),
результатов
анализа
на
определение
лейкоцитарных
антител
кандидатов на пересадку (форма №410-9/у).
Данный процесс включает, как минимум:
R2.4.1.1
Поиск пациента по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку.
R2.4.1.2
Ведение
результатов
выполненных M
исследований, включая, но, не ограничиваясь
505
Раздел VI. Технические требования
506
информацией о результатах исследования
иммунологического
типирования
тканей
высокого, среднего и низкого разрешения
молекулярным и серологическим методом лиц,
рекомендованных
к
трансплантации
и
потенциальных доноров (форма №410-10/у),
информацией о результатах индивидуальной
пробы
на
совместимость
«Кросс-матч»
потенциальных
доноров
и
лиц,
рекомендованных к трансплантации (форма
№410-11/у),
результатов
анализа
на
определение
лейкоцитарных
антител
кандидатов на пересадку (форма №410-9/у).
Ввод результатов выполненных лабораторных
исследований
R2.4.1.3
Просмотр результатов ранее
лабораторных исследований
введенных M
R2.4.1.4
Возможность
печати
результатов M
лабораторных исследований, включая, но, не
ограничиваясь информацией о результатах
исследования иммунологического типирования
тканей высокого, среднего и низкого
разрешения молекулярным и серологическим
методом
лиц,
рекомендованных
к
трансплантации и потенциальных доноров
(форма
№410-10/у),
информацией
о
результатах
индивидуальной
пробы
на
совместимость «Кросс-матч» потенциальных
доноров
и
лиц,
рекомендованных
к
Раздел VI. Технические требования
507
трансплантации
(форма
№410-11/у),
результатов
анализа
на
определение
лейкоцитарных
антител
кандидатов
на
пересадку (форма №410-9/у)
R2.4.1.5
Возможность
экспорта
лабораторных исследований
формата pdf, xls, doc.
результатов M
в документы
R2.5
Модуль «Региональный трансплантационный
координатор»
R2.5.1
Формирование запроса на исключение из М
«Листа ожидания» с указанием причины
(смерть, переезд, отсутствие необходимости в
трансплантации, появление противопоказаний
к трансплантации и другое). Данный процесс
включает, как минимум:
R2.5.1.1
Ввод заявки на исключение
из «Листа M
ожидания» с указанием причины (смерть,
переезд,
отсутствие
необходимости
в
трансплантации, появление противопоказаний
к трансплантации, отказ от трансплантации и
другое)
R2.5.1.2
Редактирование/удаление
заявки
на M
исключение
из
«Листа
ожидания»
неотправленной
на
рассмотрение
республиканскому
трансплантационному
Раздел VI. Технические требования
координатору
R2.5.1.3
Отправка заявки на исключение из «Листа M
ожидания» на рассмотрение республиканскому
трансплантационному координатору
R2.5.1.4
Возможность печати заявки на исключение из M
«Листа ожидания».
R2.5.1.5
Возможность экспорта заявки на исключение M
из «Листа ожидания» в документы формата pdf,
xls, doc.
R2.5.2
Мониторинг
доноров
(возможных, М
потенциальных,
актуальных,
а
также
добровольных). Данный процесс включает, как
минимум:
R2.5.2.1
Просмотр списка возможных доноров с M
возможностью сортировки и фильтрации по
возрасту пациента, полу пациента, диагнозу,
дате поступления и другому признаку.
R2.5.2.2
Просмотр списка потенциальных доноров с M
возможностью сортировки и фильтрации по
возрасту пациента, полу пациента, дате
поступления в ОРИТ, по органу/ткани,
которые предполагается изъять и другому
признаку.
508
Раздел VI. Технические требования
509
R2.5.2.3
Просмотр списка актуальных доноров с M
возможностью сортировки и фильтрации по
ФИО пациента, возрасту пациента, полу
пациента, по органу/ткани,
которые
предполагается изъять и другому признаку.
R2.5.2.4
Просмотр списка добровольных доноров с M
возможностью сортировки и фильтрации по
возрасту пациента, полу пациента, дате
регистрации и другому признаку.
R2.5.2.5
Поиск пациента по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку.
R2.5.2.6
Просмотр списка лиц, исключенных из списка M
добровольных доноров (отказ от донации,
появление противопоказаний к донации, смерть
и иные причины).
R2.5.2.7
Просмотр
истории
возможных доноров
изменения
списка M
R2.5.2.8
Просмотр
истории
потенциальных доноров
изменения
списка M
R2.5.2.9
Просмотр
истории
актуальных доноров
изменения
списка M
R2.5.2.10
Просмотр
изменения
списка M
истории
Раздел VI. Технические требования
добровольных доноров
R2.5.2.11
Ведение данных ежедневного отчета согласно M
Приложения 6 к настоящей Технической
спецификации
R2.5.2.12
Формирование сводных отчетных форм по M
зарегистрированным донорам (возможным,
потенциальным, актуальным) за определенный
период
R2.5.2.13
Формирование сводных отчетных форм по M
зарегистрированным добровольным донорам за
определенный период
R2.5.2.14
Возможность печати сводных отчетных форм M
по зарегистрированным донорам (возможным,
потенциальным, актуальным).
R2.5.2.15
Возможность печати сводных отчетных форм M
по
зарегистрированным
добровольным
донорам.
R2.5.2.16
Возможность экспорта сводных отчетных форм M
по зарегистрированным донорам (возможным,
потенциальным, актуальным) в документы
формата pdf, xls, doc
R2.5.2.17
Возможность экспорта сводных отчетных форм M
по
зарегистрированным
добровольным
510
Раздел VI. Технические требования
511
донорам в документы формата pdf, xls, doc
R2.5.2.18
Возможность
печати
информации
о M
зарегистрированном
доноре
(возможном,
потенциальном, актуальном, добровольном).
R2.5.2.19
Возможность
экспорта
информации
о M
зарегистрированном
доноре
(возможном,
потенциальном, актуальном, добровольном) в
документы формата pdf, xls, doc
R2.5.3
Регистрация добровольных прижизненных М
доноров (то есть лиц, изъявивших согласие на
изъятие одного из своих парных органов или
части органа/ткани) с возможностью проверки
наличия
нотариально
заверенного
согласия/отказа, путем взаимодействия с
государственной информационной системой
Единая нотариальная информационная система
посредством платформы информатизации и
интероперабельности
здравоохранения
согласно Приложения 2-1 к настоящей
технической спецификации. Данный процесс
включает, как минимум:
R2.5.3.1
Ведение
информации
прижизненном доноре
R2.5.3.2
Выбор конкретного реципиента добровольным M
прижизненным донором (по желанию донора)
о
добровольном M
Раздел VI. Технические требования
512
R2.5.3.3
Проверка наличия нотариально заверенного M
согласия быть донором, путем взаимодействия
с государственной информационной системой
Единая нотариальная информационная система
посредством платформы информатизации и
интероперабельности здравоохранения
R2.5.3.4
Ведение информации об отказе быть донором
R2.5.3.5
Проверка наличия нотариально заверенного M
отказа от донорства, путем взаимодействия с
государственной информационной системой
Единая нотариальная информационная система
посредством платформы информатизации и
интероперабельности здравоохранения
R2.5.3.6
Возможность
печати
информации
добровольном прижизненном доноре.
R2.5.3.7
Формирование сводных отчетных форм по M
зарегистрированным добровольным донорам за
определенный период
R2.5.3.8
Возможность печати сводных отчетных форм M
по
зарегистрированным
добровольным
донорам за определенный период
R2.5.3.9
Возможность экспорта сводных отчетных форм M
по
зарегистрированным
добровольным
M
о M
Раздел VI. Технические требования
513
донорам в документы формата pdf, xls, doc.
R2.5.3.10
Формирование сводных отчетных форм по M
зарегистрированным отказам быть донором за
определенный период
R2.5.3.11
Возможность печати сводных отчетных форм M
по зарегистрированным отказам быть донором
за определенный период
R2.5.3.12
Возможность экспорта сводных отчетных форм M
по зарегистрированным отказам быть донором
в документы формата pdf, xls, doc.
R2.5.3.13
Возможность
экспорта
информации
добровольном
прижизненном
доноре
документы формата pdf, xls, doc.
R2.5.4
Регистрация
добровольных
посмертных М
доноров (то есть лиц, изъявивших согласие на
изъятие после смерти своего органа/части
органа и/или ткани) с возможностью
прикрепления
сканированной
копии
согласия/отказа согласно Приложения 2-1 к
настоящей технической спецификации. Данный
процесс включает, как минимум:
R2.5.4.1
Ведение
информации
посмертном доноре
о
о M
в
добровольном M
Раздел VI. Технические требования
514
R2.5.4.2
Выбор конкретного реципиента добровольным M
посмертным донором (по желанию донора)
R2.5.4.3
Прикрепление
сканированной
нотариально заверенного согласия
R2.5.4.4
Ведение информации об отказе быть донором
R2.5.4.5
Прикрепление
сканированной
нотариально заверенного отказа
R2.5.4.6
Возможность
печати
информации
добровольном посмертном доноре.
R2.5.4.7
Возможность
экспорта
информации
о M
добровольном посмертном доноре в документы
формата pdf, xls, doc.
R2.5.4.8
Формирование сводных отчетных форм по M
зарегистрированным добровольным донорам за
определенный период
R2.5.4.9
Возможность печати сводных отчетных форм M
по
зарегистрированным
добровольным
донорам за определенный период
R2.5.4.10
Возможность экспорта сводных отчетных форм M
по
зарегистрированным
добровольным
донорам в документы формата pdf, xls, doc.
копии M
M
копии M
о M
Раздел VI. Технические требования
R2.5.4.11
Формирование сводных отчетных форм по M
зарегистрированным отказам быть донором за
определенный период
R2.5.4.12
Возможность печати сводных отчетных форм M
по зарегистрированным отказам быть донором
за определенный период
R2.5.4.13
Возможность экспорта сводных отчетных форм M
по зарегистрированным отказам быть донором
в документы формата pdf, xls, doc.
R2.6
Модуль
«Республиканский
трансплантационный координатор»
R2.6.1
Ведение реестра доноров органов/части органа М
и/или ткани(создание записей, редактирование,
удаление,
просмотр).
Данный
процесс
включает, как минимум:
R2.6.1.1
Ведение информации о донорах органов/части M
органа и/или ткани
R2.6.1.2
Исключение из регистра донора с указанием M
причины
R2.6.1.3
Поиск пациента по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку.
515
Раздел VI. Технические требования
R2.6.1.4
Возможность печати информации о донорах M
органов/части органа и/или ткани.
R2.6.1.5
Возможность экспорта информации о донорах M
органов/части органа и/или ткани в документы
формата pdf, xls, doc.
R2.6.1.6
Формирование сводных отчетных форм по M
зарегистрированным донорам органов/части
органа и/или ткани
R2.6.1.7
Возможность печати сводных отчетных форм M
по зарегистрированным донорам органов/части
органа и/или ткани
R2.6.1.8
Возможность экспорта сводных отчетных форм M
по зарегистрированным донорам органов/части
органа и/или ткани в документы формата pdf,
xls, doc.
R2.6.1.9
Формирование сводных отчетных форм по M
исключенным
из
регистра
донорам
органов/части органа и/или ткани
R2.6.1.10
Возможность печати сводных отчетных форм M
по исключенным из регистра донорам
органов/части органа и/или ткани
R2.6.1.11
Возможность экспорта сводных отчетных форм M
по исключенным из регистра донорам
516
Раздел VI. Технические требования
517
органов/части органа и/или ткани в документы
формата pdf, xls, doc.
R2.6.2
Ведение «Листа ожидания» (создание записей, М
редактирование, удаление, просмотр). Данный
процесс включает, как минимум:
R2.6.2.1
Ведение «Листа ожидания»
R2.6.2.2
Рассмотрение
запроса
Регионального M
трансплантационного
координатора
на
исключение из «Листа ожидания»
R2.6.2.3
Исключение пациента из «Листа ожидания» с M
указанием причины
R2.6.2.4
Возможность печати информации о лицах, M
нуждающихся в трансплантации
R2.6.2.5
Возможность экспорта информации о лицах, M
нуждающихся в трансплантации в документы
формата pdf, xls, doc
R2.6.2.6
Формирование сводных отчетных форм по M
зарегистрированным лицам, нуждающимся в
трансплантации
органов/тканей,
за
определенный период
R2.6.2.7
Возможность печати сводных отчетных форм M
по зарегистрированным лицам, нуждающимся
M
Раздел VI. Технические требования
в трансплантации органов/тканей
R2.6.2.8
Возможность экспорта сводных отчетных форм M
по зарегистрированным лицам, нуждающимся
в
трансплантации
органов/тканей,
за
определенный период в документы формата
pdf, xls, doc.
R2.6.2.9
Формирование сводных отчетных форм по M
пациентам, исключенным из «Листа ожидания»
за определенный период
R2.6.2.10
Возможность печати сводных отчетных форм M
по пациентам, исключенным из «Листа
ожидания»
R2.6.2.11
Возможность экспорта сводных отчетных форм M
по пациентам, исключенным из «Листа
ожидания» в документы формата pdf, xls, doc.
R2.6.3
Автоматическое направление по электронной М
почте
напоминания
о
необходимости
проведения
очередного
квартального
обследования. Данный процесс включает, как
минимум:
R2.6.3.1
Автоматическое
формирование
списков M
больных, которые должны пройти очередное
квартальное обследование на определение
лейкоцитарных антител, за 10 дней до
518
Раздел VI. Технические требования
плановой даты сдачи анализа.
R2.6.3.2
Автоматическое направление по электронной M
почте кандидату на пересадку напоминания о
необходимости
проведения
очередного
квартального обследования на определение
лейкоцитарных антител за 10 дней до даты
сдачи анализа.
R2.6.3.3
Автоматическое направление по электронной M
почте
напоминания
региональному
и
республиканскому
трансплантационному
координатору списков больных, которые
должны
пройти
очередное
квартальное
обследование на определение лейкоцитарных
антител, за 10 дней до плановой даты сдачи
анализа
R2.6.4.
Автоматический
расчет
баллов
для М
определения места в «Листе ожидания» по
таблице критериев согласно Приложения 3 к
настоящей технической спецификации. Данный
процесс включает, как минимум:
R2.6.4.1
Автоматический
расчет
баллов
для M
определения места в «Листе ожидания» по
таблице критериев согласно Приложения 3 к
настоящей технической спецификации
R2.6.4.2
Регулярный (не менее одного раза в сутки и M
519
Раздел VI. Технические требования
при
выявлении
актуального
донора)
автоматический
пересчет
баллов
для
определения места в «Листе ожидания» по
таблице критериев согласно Приложения 3 к
настоящей технической спецификации
R2.6.5
Автоматический
подбор
группы М
потенциальных реципиентов по донору.
Данный процесс включает, как минимум:
R2.6.5.1
Поиск донора по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку.
R2.6.5.2
Автоматический
подбор
группы M
потенциальных реципиентов по донору.
R2.6.5.3
Возможность печати информации о лицах, M
подобранных в качестве потенциальных
реципиентов по донору.
R2.6.5.4
Возможность экспорта информации о лицах, M
подобранных в качестве потенциальных
реципиентов по донору в документы формата
pdf, xls, doc.
R2.6.6
Автоматический
подбор
группы М
потенциальных реципиентов по донору с
учетом
потребности
в
нескольких
органах/тканях. Данный процесс включает, как
520
Раздел VI. Технические требования
минимум:
R2.6.6.1
Поиск донора по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку.
R2.6.6.2
Автоматический
подбор
группы M
потенциальных реципиентов по донору с
учетом
потребности
в
нескольких
органах/тканях.
R2.6.6.3
Возможность печати информации о лицах, M
подобранных в качестве потенциальных
реципиентов по донору с учетом потребности в
нескольких органах/тканях
R2.6.6.4
Возможность экспорта информации о лицах, M
подобранных в качестве потенциальных
реципиентов по донору с учетом потребности в
нескольких органах/тканях в документы
формата pdf, xls, doc.
R2.6.7
Автоматический подбор группы доноров по М
больному, нуждающемуся в пересадке. Данный
процесс включает, как минимум:
R2.6.7.1
Поиск больного по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку или выбор больного из
521
Раздел VI. Технические требования
«Листа ожидания».
R2.6.7.2
Автоматический подбор группы доноров по M
больному, нуждающемуся в пересадке.
R2.6.7.3
Возможность печати информации о лицах, M
подобранных в качестве потенциальных
доноров по больному.
R2.6.7.4
Возможность экспорта информации о лицах, M
подобранных в качестве потенциальных
доноров по больному в документы формата pdf,
xls, doc.
R2.6.8
Автоматический подбор группы доноров по М
больному, нуждающемуся в пересадке с учетом
потребности в нескольких органах/тканях.
Данный процесс включает, как минимум:
R2.6.8.1
Поиск больного по ФИО, ИИН, органу/части M
органа и/или ткани, группе крови, rh фактору и
другому признаку или выбор больного из
«Листа ожидания».
R2.6.8.2
Автоматический подбор группы доноров по M
больному, нуждающемуся в пересадке с учетом
потребности в нескольких органах/тканях.
R2.6.8.3
Возможность печати информации о лицах, M
подобранных в качестве потенциальных
522
Раздел VI. Технические требования
523
доноров по больному с учетом потребности в
нескольких органах/тканях.
R2.6.8.4
Возможность экспорта информации о лицах, M
подобранных в качестве потенциальных
доноров по больному с учетом потребности в
нескольких органах/тканях в документы
формата pdf, xls, doc.
R2.6.9
Ведение информации о решении консилиума о М
трансплантации. Данный процесс включает,
как минимум:
R2.6.9.1
Ведение
информации
о
консилиуме M
(участники, место проведения, дата и другое)
R2.6.9.2
Ведение информации о решении консилиума о M
трансплантации
R2.6.9.3
Возможность
печати
информации
консилиуме и принятом решении.
R2.6.9.4
Возможность
экспорта
информации
о M
консилиуме и принятом решении в документы
формата pdf, xls, doc.
R2.7
Модуль «Трансплантационная бригада»
R2.7.1.
Ведение
информации
об
отобранных М
донорских органах и тканях. Данный процесс
о M
Раздел VI. Технические требования
524
включает, как минимум:
R2.7.1.1
Ведение
информации
донорских органах
об
отобранных M
R2.7.1.2
Ведение
информации
донорских тканях
об
отобранных M
R2.7.1.3
Ведение информации об операции по отбору M
органов
(наименование
медицинской
организации, в которой произведена операция,
код МКБ-9, информация об анестезии и другое)
R2.7.1.4
Возможность
печати
информации
отобранных донорских органах и тканях.
R2.7.1.5
Возможность печати информации об операции M
по отбору органов
R2.7.1.6
Возможность
экспорта
информации
об M
отобранных донорских органах и тканях в
документы формата pdf, xls, doc.
R2.7.1.7
Возможность
экспорта
информации
об M
операции по отбору органов в документы
формата pdf, xls, doc.
R2.7.1.8
Формирование сводных отчетных форм по M
отобранным донорским органам и тканям за
об M
Раздел VI. Технические требования
определенный период
R2.7.1.9
Возможность печати сводных отчетных форм M
по отобранным донорским органам и тканям
R2.7.1.10
Возможность экспорта сводных отчетных форм M
по отобранным донорским органам и тканям в
документы формата pdf, xls, doc.
R2.7.1.11
Формирование сводных отчетных форм по M
произведенным
операциям
по
отбору
донорских органов/тканей за определенный
период
R2.7.1.12
Возможность печати сводных отчетных форм M
по произведенным операциям по отбору
донорских органов/тканей
R2.7.1.13
Возможность экспорта сводных отчетных форм M
по произведенным операциям по отбору
донорских органов/тканей в документы
формата pdf, xls, doc.
R2.7.2
Ведение информации о произведенных М
пересадках органов и тканей. Данный процесс
включает, как минимум:
R2.7.2.1
Ведение
информации
о
пересажанных M
реципиенту донорских органах/тканях
525
Раздел VI. Технические требования
526
R2.7.2.2
Ведение информации об операции по M
трансплантации
органов
(наименование
медицинской
организации,
в
которой
произведена операция, код МКБ-9, информация
об анестезии и другое)
R2.7.2.3
Ведение
информации
о
преди M
послеоперационном
периоде,
схеме
иммуносупрессивной
терапии,
послеоперационных осложнениях.
R2.7.2.4
Возможность
пересажанных
органах/тканях.
R2.7.2.5
Возможность печати информации об операции M
по пересадки органов
R2.7.2.6
Возможность
экспорта
информации
о M
пересажанных
реципиенту
донорских
органах/тканях в документы формата pdf, xls,
doc
R2.7.2.7
Возможность
экспорта
информации
об M
операции по пересадки органов в документы
формата pdf, xls, doc
R2.7.2.8
Формирование сводных отчетных форм по M
пересаженным донорским органам и тканям за
печати
информации
о M
реципиенту
донорских
Раздел VI. Технические требования
определенный период
R2.7.2.9
Возможность печати сводных отчетных форм M
по пересаженным донорским органам и тканям
за определенный период
R2.7.2.10
Возможность экспорта сводных отчетных форм M
по пересаженным донорским органам и тканям
за определенный период в документы формата
pdf, xls, doc
R2.7.2.11
Формирование сводных отчетных форм по M
произведенным операциям по пересадки
реципиенту органов/тканей за определенный
период
R2.7.2.12
Возможность печати сводных отчетных форм M
по произведенным операциям по пересадки
реципиенту органов/тканей за определенный
период
R2.8
Модуль «Мониторинг состояния лиц, которым
была произведена трансплантация»
R2.8.1
Ведение регистра лиц, которым была М
произведена трансплантация (создание записей,
редактирование, просмотр). Данный процесс
включает, как минимум:
R2.8.1.1
Ведение информации о лицах, которым была M
527
Раздел VI. Технические требования
произведена трансплантация
R2.8.1.2
Мониторинг состояния донора, от которого M
была произведена трансплантация.
R2.8.1.3
Поиск пациента по ФИО, ИИН, пересаженному M
органу/части органа и/или ткани, группе крови,
rh фактору и другому признаку.
R2.8.1.4
Возможность печати информации о лицах, M
которым была произведена трансплантация
R2.8.1.5
Возможность экспорта информации о лицах, M
которым была произведена трансплантация в
документы формата pdf, xls, doc.
R2.8.2
Мониторинг состояния здоровья лиц, которым М
была произведена трансплантация. Данный
процесс включает, как минимум:
R2.8.2.1
Ведение информации о состоянии здоровья M
лиц,
которым
была
произведена
трансплантация
R2.8.2.2
Ведение
истории
изменения
состояния M
здоровья лиц, которым была произведена
трансплантация
R2.8.2.3
Мониторинг состояния лиц, которым была M
528
Раздел VI. Технические требования
произведена трансплантация от общего донора.
R2.8.2.4
Просмотр истории изменения состояния M
здоровья лиц, которым была произведена
трансплантация с возможностью сортировки и
фильтрации по возрасту пациента, полу
пациента,
дате
регистрации,
трансплантированному органу и другому
признаку.
R2.8.2.5
Поиск пациента по ФИО, ИИН, пересаженному M
органу/части органа и/или ткани, группе крови,
rh фактору и другому признаку.
R2.8.2.6
Возможность печати информации о состоянии M
здоровья лиц, которым была произведена
трансплантация
R2.8.2.7
Возможность печати истории изменения M
состояния здоровья лиц, которым была
произведена трансплантация
R2.8.2.8
Возможность
экспорта
информации
о M
состоянии здоровья лиц, которым была
произведена трансплантация, в документы
формата pdf, xls, doc.
R2.8.2.9
Возможность экспорта истории изменения M
состояния здоровья лиц, которым была
произведена трансплантация, в документы
529
Раздел VI. Технические требования
530
формата pdf, xls, doc.
R2.9
Модуль «Формирование
статистических таблиц»
аналитических
и
R2.9.1
Отчет о проведенных аллогенных родственных М
трансплантациях (по фамильный список
реципиентов, доноров, исходов)
R2.9.2
Отчет
о
проведенных
аллогенных М
неродственных
трансплантациях
(по
фамильный список реципиентов, доноров,
исходов)
R2.9.3
Отчет по летальным исходам больных, М
состоящих на «Листе ожидания» (по возрастам,
причине смерти, дате смерти)
R2.9.4
Отчет
о
проведенных
эксплантациях: М
информация об отобранных органах, причинах
не произведенного отбора, медицинской
организации, где был произведен отбор
R2.9.5
Отчет о случаях констатации смерти М
мозга/остановки
кровообращения
потенциального донора (по фамильный список,
даты смерти)
R2.9.6
Ежемесячные отчеты согласно Приложении 4, М
Раздел VI. Технические требования
531
5 к настоящей Технической спецификации
R2.9.7
Ежедневный
отчет
регионального М
трансплантационного координатора согласно
Приложения 6 к настоящей Технической
спецификации
R2.9.8
Все выходные формы должны иметь М
возможность распечатки и сохранения в
формате xls, pdf, doc.
R3
Требования к конфигурации системы
R3.1
Конфигурация к потребностям медицинских
организаций
R3.1.1
Система должна обеспечить возможность М
управления доступом к функционалу на основе
ролей.
Система
должна
позволять
добавлять/удалять/редактировать
роли
и
присвоить/отменить
право
доступа
к
функционалу системы.
R3.1.2
Система должна иметь предустановленные М
роли в соответствии с p.1.1.2.5. настоящей
технической спецификации с возможностью
дальнейшего изменения (добавления новых
ролей, редактирования или удаления).
R3.1.3
Права
доступа
к
различным
модулям
и М
Раздел VI. Технические требования
функциям
системы
должны
быть
предустановлены в соответствии с Таблицей 1
с возможностью изменения прав доступа
(добавления, удаления)
R3.1.4
Права доступа должны быть как минимум М
конфигурируемыми по следующим аспектам:
все права, создание, изменение, удаление,
просмотр.
R3.1.5
Система должна включать мастер отчетных M
форм, позволяющий создавать и редактировать
отчеты с использованием полей из базы данных
Системы
R4
Требования к времени реакции системы
R4.1
Поиск пациента по ФИО или ИИН, а также M
связанных с пациентом данных (результаты
обследования,
результаты
лабораторных
исследований и другое) не должен занимать
более 5 секунд для 80% случаев
R4.2
Поставщик в течение гарантийного срока М
должен обеспечивать следующие параметры
функционирования системы:
R4.3
Суммарное время простоя Системы по М
причинам, связанным с ее работоспособностью
532
Раздел VI. Технические требования
533
не должно превышать 24 часов в год.
R4.4
Время однократного простоя Системы по М
причинам, связанным с ее работоспособностью
не должно превышать 2 часов.
R5
Требования к информационной безопасности
R5.1
Требования
безопасности
определяются M
действующим законодательством Республики
Казахстан. Система должна соответствовать
требованиям информационной безопасности по
обеспечению порогового доступа, защите от
несанкционированного доступа и другого.
R5.2.
В системе должны быть предусмотрены M
средства
защиты
информации
от
несанкционированного доступа, а именно:
R5.2.1
Идентификация пользователя на основе M
проверки имени (логина) пользователя и
пароля
R5.2.2
Возможность идентификации пользователя, M
основанной на цифровых сертификатах
инфраструктуры открытых ключей
R5.2.3
Авторизация пользователя для
информационно-вычислительным
Системы,
требующим
доступа к M
ресурсам
наличия
Раздел VI. Технические требования
соответствующих разрешений
R5.2.4
Персонифицированное
определение
прав M
пользователей
на
ввод,
корректировку,
просмотр данных
R5.2.5
Персонифицированное
определение
прав M
пользователей на доступ к ресурсам Системы
R5.2.6
Разграничение прав пользователей системы по M
ролям, группам и уровню доступа с учётом
иерархии объектов и принадлежности к
организационной структуре.
R5.2.7
Протоколирование работы пользователей с M
критическими функциями и приложениями
Системы
R5.2.8
Защиту
системных
файлов
от M
изменения/повреждения
неавторизованными
пользователями и программными процессами
R5.2.9
Должен вестись контрольный журнал всех M
обновлений
в
библиотеках
системных
программ
R5.3
В системе должны быть реализованы не менее M
чем
следующие
средства
резервного
копирования:
534
Раздел VI. Технические требования
- автоматическое резервное копирование с
возможностью планирования
- удаленное управление созданием резервной
копии
- полное и частичное резервное копирование
R5.4
Система должна обеспечивать целостность M
данных.
R5.5
Система должна предоставлять инструменты M
для шифрования конфиденциальных данных во
время хранения и в процессе передачи в другие
системы.
R5.6
Электронно-цифровая подпись (далее - M
регистрационное свидетельство пользователя
Национальным Удостоверяющим Центром
Республики Казахстан, ЭЦП) должна быть
выпущена НУЦ РК. Система должна
обеспечить инструменты для цифровой
подписи документов (объектов) или частей
документов, когда/если это необходимо, и
инструменты для аутентификации подписей.
Эта возможность должна быть реализована в
сервисах Системы (если это необходимо). Для
обеспечения подтвреждения полдинности ЭЦП
и действительности открытого ключа ЭЦП,
Система должна осушествлять проверки
подлинности ЭЦП посредством сервисов НУЦ
535
Раздел VI. Технические требования
536
РК. (http://pki.gov.kz/index.php/ru/).
R5.7
Система должна соответствовать принципу M
«единой точки доступа» - архитектура
информационной
инфраструктуры,
позволяющая иметь общую точку доступа
(технология Single Sign On) ко всем ее
компонентам и ресурсам, что позволяет ввести
логин и пароль один раз и получить доступ ко
всем компонентам Системы без повторного
ввода пароля.
R5.8
Система должна обеспечивать авторизацию M
пользователей в Системе, разграничение прав
пользователей системы по ролям, группам и
уровню доступа с учётом иерархии объектов и
принадлежности к организационной структуре.
R5.9
В соответствии с нормативно-технической M
документацией
по
информационной
безопасности, утвержденной МЗСР РК, должно
быть реализовано следующее:
− длина пароля должна быть не менее 8
символов, должны присутствовать буквы и
цифры в верхнем и нижнем регистрах;
− функция принудительной смены пароля;
− функция запрета использования
качестве пароля «пустой» пароль;
− самостоятельная
смена
в
пароля
Раздел VI. Технические требования
пользователем;
− при
введении неправильного пароля
более трех раз должен быть реализован метод
CAPTCHA;
− журнал
логирования действий всех
пользователей,
предназначенный
для
просмотра истории изменений основных
событий Системы;
− функционал прерывания сессии при
неактивности через N количество времени.
R6
Требования к атрибутам качества системы
R6.1.
Система
должна
поддерживать
ввод, M
получение и передачу данных необходимых
для работы ИС МЗСР РК используемых
Организацией и исключать необходимость
повторного ввода данных.
R6.2
Система должна обеспечивать сохранение всей M
накопленной на момент отказа или выхода из
строя информации при отказе любого
компонента Системы независимо от его
назначения, с последующим восстановлением
после
проведения
ремонтных
и
восстановительных работ
R6.3
Система должна иметь возможность гибкой M
настройки при изменении внешней среды и
537
Раздел VI. Технические требования
538
конкретных задач пользователя без замены
модулей.
R6.4
Система должна быть высоко масштабируемой M
и
позволять
работать
в
системе
неограниченному количеству пользователей.
Ограничения могут обуславливаться только
техническими характеристиками оборудования,
а не характеристиками Системы
R6.5
Все функциональные возможности системы M
должны быть разработаны в виде сервисов.
R6.6
Веб-сервисы
Системы
должны
разработаны
в
соответствии
с
архитектурой.
R6.7
При реализации
сервисов взаимодействия М
обязательно придерживаться стандарта МЗСР
РК, касающегося взаимодействия ИС
R6.8
Система должна предусматривать возможность M
конструирования шаблонов утвержденных
медицинских форм, доступных в пределах
самого решения, которые могут быть
автоматизированы без программирования или
внесения изменений в программный код.
R6.9
Система должна обеспечивать разрешение M
конфликтов при параллельной обработке
быть M
СОА
Раздел VI. Технические требования
объектов системы.
R7
Требования к пользовательскому интерфейсу
R7.1
Интерфейс должен быть рассчитан на M
преимущественное
использование
манипулятора
типа
«мышь»,
то
есть
управление системой должно осуществляться с
помощью набора экранных меню, кнопок,
значков и тому подобных элементов
R7.2
Клавиатурный
режим
ввода
должен M
использоваться
главным
образом
при
заполнении и/или редактировании текстовых и
числовых полей экранных форм. Также
должны быть предусмотрены горячие клавиши
для перехода между заполняемыми полями.
R7.3
Эргономические
решения
и
дизайн M
интерфейсов по возможности должны быть
едиными для всех компонентов и модулей
Системы
R7.4
Пользовательский интерфейс Системы должен M
быть многоязычным и организован с
поддержкой не менее чем государственного
(казахского) и русского языков. Исключения
могут составлять только системные сообщения,
не подлежащие локализации или стандартные
административные приложения, входящие в
539
Раздел VI. Технические требования
состав
общесистемного
обеспечения
540
программного
R7.5
Должен быть обеспечен доступ к электронному M
комплекту эксплуатационной документации
R7.6
В Системе должна быть реализована M
контекстно-зависимая справочная система,
доступная из любых страниц веб-приложения,
где должны быть представлены ссылки на
информацию
(Руководство
пользователя,
инструкции и др.) для работы, с возможностью
конфигурации
без
привлечения
Потенциального Поставщика на уровне
Покупателя;
R7.7
В пользовательском интерфейсе Системы M
должно быть предусмотрено визуальное
выделение на экране атрибутов, доступных
оператору только для чтения
R7.8
В пользовательском интерфейсе Системы M
должно быть предусмотрено визуальное
выделение на экране атрибутов, обязательных
для заполнения
R7.9
Система должна обеспечивать корректную M
обработку аварийных ситуаций, вызванных
неверными
действиями
пользователей,
неверным форматом или недопустимыми
Раздел VI. Технические требования
значениями входных данных. В указанных
случаях
Система
должна
выдавать
пользователю соответствующие сообщения,
после чего возвращаться в рабочее состояние,
предшествовавшее неверной (недопустимой)
команде или некорректному вводу данных
R7.10
Система не должна позволять дублирование и M
повторный (ошибочный) ввод однородной
информации. Система должна обеспечивать
исключение дублирования и повторного ввода
информации, содержащейся в государственных
базах данных и информационных системах
государственных органов.
R7.11
Система должна обеспечивать форматно- M
логический контроль вводимых данных. Под
форматно-логическим контролем вводимых
данных понимается контроль на формат и
содержание вводимых данных. При работе
Системой должна быть предусмотрена защита
от ошибочных действий:
- выбор только доступных для пользователя (в
соответствии с правами доступа) функций;
- ввод только доступных для пользователя (в
соответствии с правами доступа) значений;
- ввод данных только определенного формата
(например, невозможность ввода символьных
данных в поле формата «Дата» или «Число»).
541
Раздел VI. Технические требования
R8.
Требования к взаимодействию Системы
R8.1.
Общие требования к интероперабельности
Системы
R8.1.1
Решения и приложения Системы должны M
соответствовать
стандартам
интероперабельности,
в
том
числе
национальным
стандартам
и
принятым
международным стандартам, перечисленным в
этой главе (и в этом документе).
R8.1.2
Компоненты Системы должны соответствовать M
национальным инструментам семантики:
o
Справочники и классификаторы
o
Требования к сервисам справочников
o
Требования к регистрам и сервисам регистров
Детали по требованиям для этих инструментов
приведены в этом разделе ниже (R8.3)
R8.2
Совместимость со стандартами
R8.2.1
Компоненты
Системы
должны
быть M
совместимы не менее чем со следующими
стандартами МЗСР РК:
1) Стандартные требования к электронному
паспорту здоровья (требующий соблюдения EN
542
Раздел VI. Технические требования
13940)
2) Стандартные требования к электронной
медицинской записи (требующий соблюдения
EN 13940)
3) Стандартные требования к идентификации
действующих
сторон
здравоохранения,
используемых в системах электронного
здравоохранения
4) Технические требования к взаимодействию
(передаче сообщений) с информационными
системами электронного здравоохранения
5) Регламент по обеспечению информационной
безопасности
6) Стандартные требования к единому
классификатору
лекарственных
средств,
изделий
медицинского
назначения
и
медицинской техники
7) Стандартные требования к реализации и
регулированию электронных направлений
8) Регламент взаимодействия
заинтересованных сторон с целью обеспечения
интероперабельности информационных систем
и управления информационными потоками
9) Стандарт регулирования ведения рецептов в
электронном формате
10) Стандарт управления электронными
процессами диагностических исследований и
лечебных процедур
543
Раздел VI. Технические требования
11) Стандарт регулирования
профилактики заболеваний
544
электронной
Указанные
стандарты
и
нормативные
документы
доступны
по
ссылке
https://www.mzsr.gov.kz/taxonomy/term/619
R8.2.2
Компоненты
Системы
должны
быть M
совместимы со следующими международными
стандартами:
EN 13940 (в части необходимости
соответствия стандартам ЭПЗ и ЭМЗ)
a.
HL7 (ISO/HL7 27831) , HL7 (v2 или V3
или FHIR);
b.
R8.2.3
c.
HL7 CDA R2 (ISO/ HL7 27932)
d.
DICOM
Система должна соответствовать требованиям M
стандартам по информационной безопасности:

СТ РК ИСО/МЭК 27001-2008 «Методы
и средства обеспечения безопасности системы
управления информационной безопасностью.
Требования»;

СТ РК ИСО/МЭК 27002-2009
«Информационная технология. Средства
обеспечения. Свод правил по управлению
защитой информации».
R8.3
Требования к совместимости с национальными
Раздел VI. Технические требования
идентификаторов
и
стандартными
классификаторами / справочниками
R8.3.1
Компоненты Системы должны поддерживать и M
соответствовать требованиям к национальным
идентификаторам:
- Идентификатор Пациентов
- Идентификатор организаций здравоохранения
- Идентификатор медработников
- Идентификатор медицинской техники
R8.3.2
Компоненты Системы должны поддерживать и M
соответствовать требованиям, как минимум по
следующим классификаторам и справочникам:
1)
Национальный
классификатор
лекарственных
средств
и
медицинских
материалов (картированный к АТС- DDD )
2) Классификатор медицинских услуг (на
основе МКБ-9, раздел по услугам и .3)
3) Классификатор результатов лабораторных
исследований
4) Классификатор услуг и их стоимости
5) Классификатор диагнозов (МКБ-10)
6) Классификатор ПМСП (ICPC-2)
7) Картирование ICPC-2 и МКБ-10
545
Раздел VI. Технические требования
8) SNOMED, (только для цели кодирования
связи между Системой и Репозиторием ЭПЗ)
9) Для управления диагностическими услугами
улучшенная система классификации, должна
быть определена на более позднем этапе;
10) Реализованная МЗ, национальная система
КЗГ для классификации пациентов (при
оказании специализированной помощи);
11) Классификатор регистров целевых групп
пациентов (Диспансерные группы);
12) Тарификатор медицинских услуг;
13) Специальностей здравоохранения;
14) Список должностей
R8.4
Требования к совместимости / соответствию
данных
R8.4.1
Компоненты Системы должны обеспечивать M
связь между Системой и Платформой,
содержащей Репозиторий ЭПЗ, основываясь на
следующих данных:
- минимальный набор данных для ЭПЗ
(приводится в Приложении к Национальному
стандарту ЭПЗ и Национальному стандарту
ЭМЗ)
- другие данные, не покрытые семантическими
стандартами, но необходимыми согласно НПА
546
Раздел VI. Технические требования
547
МЗСР РК, такие как Прикрепленные
специальные записи (документы, основанные
на CDA)
R8.4.2
Система должна обеспечивать доступ к M
данным, хранящимся в Репозитории ЭПЗ, в
соответствии с 2 типами ЭПЗ: Полный ЭПЗ,
Краткий ЭПЗ. Подробности описаны в
Национальном стандарте ЭПЗ
R8.4.3
Данные передаются между Системой
Репозиторием ЭПЗ в формате CDA
R8.4.4
Система должна предоставлять возможность M
передачи данных в Репозиторий ЭПЗ на основе
кодов ICPC-2, которые используются в
посещениях (и контактах в целом) и
картированы к МКБ-10 для целей сбора
статистики. В ИС ЭМЗ (кроме систем ЭПЗ/
ПМСП)
специалисты
используют
для
кодирования
диагностики
МКБ-10,
и
картирование в обратном направлении не
является обязательным, лишь желательным.
R8.4.6
Система должна быть достаточно открытой, M
чтобы
быть
способной
обеспечить
интероперабельность с существующими ИС
МЗСР РК, приложениями и сервисами
R8.5
Требования к информационному обмену
и M
Раздел VI. Технические требования
R8.5.1
Система
должна
взаимодействовать
с M
национальной системой ЭПЗ в соответствии с
Национальными стандартами ЭПЗ и ЭМЗ.
R8.5.2
Система должна поддерживать (как минимум) M
взаимодействие со следующими наборами
сервисов электронного здравоохранения:




Сервисы репозитория ЭПЗ;
Сервисы справочной информации;
Сервисы регистрации и регистров;
Сервисы Клинической Номенклатуры и
классификации данных;

Сервисы безопасного обмена
информацией и обмена сообщениями;

Сервисы идентификации и
аутентификации;
Сервисы мониторинга и аудита для
информационного обмена.
R8.5.3
Система должна соответствовать как минимум M
следующим профилям IHE:
a) Инфраструктурные профили IHE:
R8.5.4

ATNA;

XDS.b;

PDQ;

PIX;
Система должна обеспечить возможности M
взаимодействия/интеграции с использованием
548
Раздел VI. Технические требования
как минимум
спецификаций:
549
следующих
протоколов
и
a. Коммуникацию через SOAP (и сообщения
SOAP с приложением), REST, Message
Transmission Optimization Mechanism;
b. Поддержка стандартов и спецификаций веб-
сервисов (WS-Security, WS-Addressing, WSReliable Messaging, WS-coordination, WSTransaction, WS-Secure Conversation);
c. Соответствовать стандартам XML (XML,
XSL, ebXML, и др.);
d. Поддерживать SSO и контроль доступа
через SAML v2, JWT;
e. Поддерживать общие стандарты, такие как
HTTP,
HTTPS,
TCP/IP,
протоколы
защищённых сокетов (SSL v3) и TLS;
f. Позволить использование WSDL, WADL;
g. X.509;
Цифровые подписи (ЭЦП НУЦ РК).
R8.5.5
Система
UTF8.
должна
поддерживать
кодировку M
R8.5.6
Система
должна
взаимодействовать
с М
сервисами Платформы при скорости канала 1
Мб/с и времени отклика не более 100 мс
Раздел VI. Технические требования
550
R8.6
Межсистемное взаимодействие
R8.6.1
Взаимодействие с ИС МЗСР РК в части M
получения
данных
о
медицинских
организациях,
функциональных
подразделениях и сотрудниках медицинских
организаций, а также общей справочной
информации, использующейся в ИС МЗСР РК
R8.6.2
Взаимодействие с ИС МЗСР РК с целью M
получения данных о лицах, состоящих на
диспансерном учете
R8.6.3
Взаимодействие с ИС МЗСР РК в части M
получения данных о физических лицах и их
прикреплении, смерти (причина смерти, дата
смерти)
R8.6.4
Взаимодействие с ИС МЗСР РК в части M
получения сведений о пребывании пациента в
стационаре (форма № 066/у)
R8.6.5
Система
должна
взаимодействовать
сервисами Платформы в части:

с M
передачи/получения уведомлений и
других сведений, носящих информационный
характер
на
шлюз
«электронного
правительства»;

отправки SMS-уведомлений и других
видов рассылки посредством СМС-шлюза
Раздел VI. Технические требования
системы Мобильное правительство;

отправки электронных писем пациентам
посредством единой электронной почтовой
системой;

получения сведений о доверенностях из
государственной информационной системы
Единая
нотариальная
информационная
система;

получения сведений по записям на
прием к врачу;

получения минимальной информации о
сотруднике.
R9
Использование
национальных
ресурсов
электронного здравоохранения и инструментов
Платформы
R9.1
Система
должна
быть
способна M
функционировать в соответствии с общей
архитектурой электронного здравоохранения
(Рисунок 2)
R9.2
Система должна быть способна использовать M
функционал и веб-сервисы, опубликованные на
национальном уровне для взаимодействия с
ресурсами электронного здравоохранения.
R9.3
Система должна быть способной использовать M
репозиторий
ЭПЗ,
национальные
классификаторы и индексы (как минимум
Главный
индекс
пациента,
индекс
551
Раздел VI. Технические требования
подразделений медицинских организаций,
индекс сотрудников, индекс зданий, адресный
индекс,
индекс
автотранспорта,
индекс
медицинской
техники),
аналитическое
хранилище и другие национальные ресурсы,
необходимые для интеграции «под-ключ»
согласно
национальным
стандартам
(перечисленные в Приказе МЗ РК №75 от
10.02.2014 года)
R9.4
Система должна поддерживать локальные M
копии национальных ресурсов и быть
способной синхронизировать их на регулярной
основе (в соответствии с настраиваемым
графиком) или онлайн. Система должна
содержать только информацию, касающуюся
деятельности
медицинской
организации.
Например, Главный индекс пациентов должен
содержаться локально только для перечня
пациентов, обслуживающихся в данной
организации.
R10
Взаимодействие со сторонами, вовлеченными
в процесс сертификации
R10.2
Поставщик системы должен взаимодействовать M
с Поставщиком Платформы, Организацией и
МЗСР
РК
в
целях
тестирования и
сертификации
интероперабельности
с
национальными ресурсами и сервисами.
552
Раздел VI. Технические требования
R10.3
Поставщик системы должен координировать M
взаимодействие
вовлеченных
сторон
в
соответствии с Рисунком 3. Сертификация
заключается в проверке
установленной
системы на соответствие требованиям R8.2.
Покупатель
уполномочит
специальную
комиссию, которая совместно с Поставщиком
Платформы и поставщиком данной системы,
проведут тесты, на соответствие требованиям
по интероперабельности в соответствии с
национальными стандартами, в том числе на
способность
корректного
взаимодействия
поставленной системы, с национальными
ресурсами
предоставленными
в
рамках
платформы.
R10.4
На этапе проектирования Системы (действие M
4.4) Поставщик Системы должен соблюдать
требования «Регламентов разработки вебсервисов» и «Требования к взаимодействию с
Репозиторием
ЭПЗ»
предоставляемые
поставщиком Платформы. Поставщик Системы
может запросить дополнительную информацию
при
необходимости
для
разработки
взаимодействия с ресурсами электронного
здравоохранения.
R10.5
На этапе тестирования/сертификации (действие M
4.6) поставщик Системы должен соблюдать
требования
и
стандарты
электронного
553
Раздел VI. Технические требования
здравоохранения R8.2
R10.6
Поставщик обязан сертифицировать систему M
до приемки в эксплуатацию.
R10.7
В случае, возникновения обстоятельств, не M
позволяющих выполнить требование R10.6 и
происходящих не по вине Поставщика, Акты
приемки Системы могут быть подписаны без
сертификации. При этом поставщик Системы
обязуется сертифицировать систему когда
появляются
условия сертификации, без
дополнительных
затрат
со
стороны
Покупателя.
R10.8
Система должна предоставлять возможность M
функционирования
на
удаленной
инфраструктуре
и
в
облачной
(виртуализированной) операционной среде
R10.10
Поставщику Системы будет предоставлен
доступ к национальным ресурсам электронного
здравоохранения
только после того, как
параллельный
контракт
будет
успешно
реализован. В целях облегчения параллельной
реализации
необходимо
синхронизировать/координировать совместные
действия с поставщиком Платформы. В случае,
возникновения обстоятельств не позволяющих
выполнить требования по взаимодействию с
554
Раздел VI. Технические требования
Платформой, ввиду задержки выполнения
котракта по поставке Платформы, поставщик
Системы
обязуется
реализовать
взаимодействие, когда появятся условия, без
дополнительных
затрат
со
стороны
Покупателя.
R11
Требования к поставщикам
R11.1
Поставщик
будет
поставлять
свою M
собственную Систему (компоненты и продукты
составляющие ее) или будет уполномочен
Разработчиком/владельцем
этой
Системы
(компонентов и продуктов составляющих ее) на
обеспечение,
разработку,
установку,
сопровождение продукции в соответствии с
настоящим тендером.
R11.2
Поставщик будет проводить обучение в стране M
клиента, связанное с использованием и
администрированием Системы, а также для
всех
разработанных
и
установленных
продуктов.
Языками
обучения
будет
государственный и русский. Детали по
обучению приведены в R13.2
R11.3
Поставщик должен иметь офис в стране M
Покупателя
или
иметь
партнера,
зарегистрированного в качестве юридического
лица в стране Покупателя, имеющего
555
Раздел VI. Технические требования
556
официальный статус партнера разработчика /
поставщика, или имеющего соглашение о
консорциуме, связанном с этим конкретным
контрактом. Это необходимо во время
реализации, развертывания, обучения и
гарантийного срока для гладкой и надежной
реализации контракта.
R11.4
Поставщик должен иметь команду реализации M
проекта, состоящую не менее чем из
следующих
специалистов
(в
случае
необходимости, две позиции могут быть
приняты одним специалистом при условии, что
навыки будут доказаны, но не более чем 2
позиции на специалиста):
1) Бизнес-аналитик, имеющий опыт работы не
менее 3 лет в ИТ проектах электронного
здравоохранения и опытом работы хотя бы в
одном аналогичном проекте;
2)
Менеджер
управления
проекта
(руководитель команды), имеющий опыт
работы не менее 3 лет в управлении проектами
и опыт работы более 1 года, где предлагаемое
решение было реализовано и должен иметь
сертификат управления проектами (например,
PMP или IPMI не менее Level B);
3) Специалист СУБД имеющий, не менее 3 лет
опыта работы с СУБД;
4)
Специалисты
с
опытов
работы
со
Раздел VI. Технические требования
стандартами не менее 2 лет: HL7, DICOM, CDA
(R2), IHE;
5) Дизайнер пользовательского интерфейса,
имеющий опыт работы не менее 3 лет;
6) Технический писатель, имеющий опыт
работы не менее 2 лет;
7) Специалист по связям, имеющий опыт
работы в данной области не менее 3 лет общего
опыта ИТ, с отличным владением английским,
русским и казахским языками;
8) Специалист по тестированию, имеющий не
менее 3 лет опыта тестирования ПО;
9) Специалист по обучению, имеющий не
менее 3 лет опыт в проведении обучения;
Все предлагаемые специалисты должны иметь
высшее образование в ИТ или взаимосвязанных
областях, степень магистра предпочтительна.
Поставщик должен представит перечень
специалистов,
с
приложением
резюме,
сертификатов для доказательства опыта работы
и квалификации.
R11.5
Поставщик должен представить все документы M
(патенты,
лицензии,
свидетельства
о
государственной регистрации прав на объект
авторского права и т.п.) на Систему (для всех
компонентов и продуктов), демонстрирующие
557
Раздел VI. Технические требования
разрешение владельцев использовать продукты
для данного контракта или демонстрирующие
владение продуктами.
R11.6
План - график оказания услуг должен быть M
согласован с уполномоченной организацией
Покупателя и подписан Покупателем в течение
20 (двадцати) рабочих дней после подписания
договора. Поставщик должен своевременно
оказывать услуги согласно утвержденному
план-графику.
R11.8
Производители ПО должны иметь как M
минимум один сертификат из следюущего
перечня: Capability Maturity Model Integration
(CMMI), ISO 9000 series, СТ РК ISO 9001:2009
или эквивалент по менеджменту качества
(Участник торгов должен представить копии
сертификатов
соответствия
выданных
уполномоченным органом)
R11.9
Поставщик должен обеспечить обслуживание и M
техническую и гарантийную поддержку,
включая
предоставление
новых
версий
продуктов в соответствии с R13.3 и R13.4.
R11.10
Поставщик
должен
подготовить M
соответствующие руководства для всех
компонентов
Системы
на
английском,
казахском и русском языках.
558
Раздел VI. Технические требования
R11.11
Поставщик должен иметь доказанный опыт M
работы со стандартами, используемыми в
настоящем документе: HL7 (v2, V3, FHIR),
CDA (R2), IHE.
R12
Общие технические требования к Системе
R12.1
Система должна иметь централизованную М
архитектуру и быть разработанной в виде вебприложения, в котором клиентом выступает
браузер, а сервером – веб-сервер.
R12.2
Доступ к клиентскому приложению должен М
осуществляться посредством любого из
следующих Интернет-браузеров: MS Internet
Explorer, Google Chrome, Opera, Safari, Mozilla
Firefox
R12.3
Серверная
часть
Системы
должна M
поддерживать работу как минимум в
операционных системах семейства Windows.
R12.4
Клиентская
часть
Системы
должна M
поддерживать работу как минимум в
операционных
системах
Windows
(2008/VISTA/7/8) (x86/x64)
R12.5
Для сохранения информации в Системе должна M
использоваться реляционная база данных.
559
Раздел VI. Технические требования
560
R12.6
База данных Системы должна поддерживать M
стандартный SQL, совместимый со стандартом
ANSI/ISO/IEC 9075-1992
R12.7
Поставщик обязан обеспечить обслуживание и M
техническую
поддержку,
включая
предоставление новых версий продуктов до
истечения срока гарантийного обслуживания
R12.8
Система должна предоставлять возможность M
аутентификации с использование технологии
SSO
R13
Спецификация услуг
R13.1
Требования к
функционала.
R13.1.1
В случае поставки и внедрения Системы M
отличной от эксплуатируемой заказчиком
Исполнитель осуществляет полный комплекс
необходимых работ по наследованию данных и
функционала,
используемых
Заказчиком
модулей
информационной
системы
с
подключением к Системе используемых
Заказчиком программных и технических
средств автоматизации, медицинского и
лабораторного оборудования.
R13.1.2
Все
затраты,
наследованию
связанные
с
данных
и
обеспечением M
Раздел VI. Технические требования
наследования данных и функционала несет
Исполнитель.
R13.2
Обучение и учебные материалы
R13.2.1
Поставщик должен подготовить учебный план M
для обучения следующих групп:
i)
пользователи системы;
j)
администраторы системы;
k) разработчики,
l)
администраторы баз данных.
Учебный план и учебные материалы по каждой
группе
должны
быть
согласованы
с
Покупателем до начала обучения.
R13.2.2
Поставщик должен обеспечить оборудование, M
презентационные материалы и пособия,
необходимые для обучения
R13.2.3
Поставщик Системы должен представить M
учебные материалы в форме руководств,
учебных книг и презентаций, баз знаний на
государственном и русском языках.
R13.2.4
Поставщик должен провести обучение как M
минимум 80 часов для каждой группы
администраторов системы, разработчиков,
администраторов баз данных и 20 часов для
561
Раздел VI. Технические требования
пользователей
каждой
медицинской
организации, в которой проводится внедрение
Системы. Количество часов может быть
увеличено и должно быть достаточно для
передачи знаний и навыков.
R13.2.5
Поставщик должен проводить отдельное M
обучение для пользователей и администраторов
системы, разработчиков, администраторов баз
данных. Индикативное число обучаемых
определяется путем умножения на 2 общего
количества автоматизированных рабочих мест
из Приложения 7. Место обучения –
юридический адрес медицинской организации
– бенефициара . Группы обучающихся должны
включать не более 10 человек
R13.2.6
Учебный план для группы (а) - пользователи M
системы - должен содержать детальное
разъяснение
автоматизированных
бизнес
процессов, использование всех компонентов
системы, подробное описание функций и
взаимодействий
между
различными
пользователями и ролями; отчётность и другая
необходимая информация. Обучение также
будет содержать практические тренинги для
понимания материала.
R13.2.7
Учебный
план
для
группы
(b)
- M
администраторы системы - должен содержать
562
Раздел VI. Технические требования
описание инструментов администрирования
компонентов системы, включая важные
вопросы сопровождения системы, и аспекты
технической поддержки.
R13.2.8
Поставщик должен провести для группы (c) M
разработчики один вводный курс и один курс
повышения квалификации по предоставляемым
средствам
разработки
и
компонентам,
предусмотренных в рамках данного контракта.
R13.2.9
Поставщик должен провести для группы (d) M
администраторы баз данных один вводный
курс и один курс повышения квалификации по
предоставляемой СУБД.
R13.2.10
Обучение для групп (a) - (d) должно M
проводиться на русском языке или на
госсударственном языке по требованиям
Покупателя.
R13.2.11
Все тренинги проводятся тренерами в Астане M
или в другом месте, указанном Покупателем.
R13.2.12
Для всех проведенных тренингов, Поставщик M
должен
провести
соответствующее
тестирование и выдавать сертификаты.
R13.3.
Служба поддержки пользователей
563
Раздел VI. Технические требования
R13.3.1
Поставщик должен организовать службу M
поддержки
пользователей
для
консультирования по вопросам, возникающим
в процессе эксплуатации, на все время
внедрения и обеспечения гарантийного
обслуживания.
R13.3.2
Техническая поддержка Системы и её M
пользователей
должна
осуществляться
Поставщиком в режиме 24 часа в сутки, 7 дней
в неделю, в течение 2 лет с момента
подписания
актов
ввода
Системы
в
эксплуатацию.
R13.4.
Гарантийный сервис
R13.4.1
Поставщик Системы будет обеспечивать M
гарантийное обслуживание Покупателя в
течение 3 лет, начиная сразу после
согласования Покупателем Акта приемки.
R13.4.2
Поставщик должен обеспечить разрешение M
запросов:
e) для
критичных
проблем,
касающихся
работоспособности Системы и ведущих к
повреждению данных, проблема должна быть
решена не более чем за 2 часов;
f) для не критичных проблем не более 2 дней.
564
Раздел VI. Технические требования
R13.4.3
Гарантийное обслуживание включает в себя, M
но
не
ограничивается,
следующими
категориями услуг:
- Исправление ошибок в Системе;
- Помощь Организации в правильном
исправлении всех проблем с данными,
возникающими в результате ошибочной
функции приложений;
- Обеспечение технической поддержки в
настройке
приложения
или
изменения
параметров по умолчанию;
- Оказание необходимой технической помощи
квалифицированному
персоналу
и
переподготовка, если выявлено, что они не
могут решить все проблемы после полученной
подготовки;
R13.4.4
Формы вмешательства могут быть одним из M
следующих наиболее подходящих с точки
зрения качества и эффективности:
○
Телефонные звонки;
○
По электронной почте;
○
Skype или другие Video Messenger;
○
Удаленный доступ к пользователю;
○
Работа на месте.
565
Раздел VI. Технические требования
566
R13.4.5
Поставщик должен обеспечить в течении M
гарантийного срока группу консультантов,
доступных в стране Покупателя в том числе
одного менеджера и как минимум одного
технического специалиста, и предоставить всех
необходимых специалистов на расстоянии для
дистанционной
помощи
(по
мере
необходимости).
R13.4.6
Суммарное время простоя Системы по M
причинам, связанным с её работоспособностью
не должно превышать 24 часов в год.
R13.4.7
Время однократного простоя Системы по M
причинам, связанным с её работоспособностью
не должно превышать 2 часов.
R14
Требования к документации
R14.1
Поставщику
необходимо
следующий пакет документов:
предоставить M
●
Программа и методика испытаний;
●
Формуляр
(основные
характеристики,
комплектность и сведения об эксплуатации
депонируемого программного продукта);
●
Описание наиболее распространенных ошибок
и способов их устранения;
●
Описание структуры базы данных;
Раздел VI. Технические требования
по
567
●
Руководство
обеспечения;
установке
●
Руководство администратора;
●
Руководство пользователя.
программного
R14.2
Языками документов должны быть
минимум государственный и русский.
как M
R14.3
Поставщик должен предоставить 5 комплектов M
документации в бумажном и электронном виде
на английском, русском и казахском языках.
Электронные версии должны поддерживать
возможность контекстового поиска.
R14.4
Поставщик
должен
подготовить M
информационную систему и нормативнометодическую документацию к проведению
аттестации на соответствие требованиям
информационной безопасности согласно со
статьей 5 Закона Республики Казахстан от 11
января 2007 года «Об информатизации» и
Постановлением Правительства Республики
Казахстан от 30 декабря 2009 года № 2280 «Об
утверждении Правил проведения аттестации
государственных информационных систем и
негосударственных информационных систем,
интегрируемых
с
государственными
информационными системами, на соответствие
их требованиям информационной безопасности
Раздел VI. Технические требования
и принятым на территории Республики
Казахстан стандартам» и к вводу в
эксплуатацию в соответствии со статьей 17
Закона Республики Казахстан от 11 января 2007
года «Об информатизации».
R15
R15.1
Тестирование системы и требования гарантии
качества
Предпусковые работы
R15.1.1
Поставщик Системы должен выполнять M
стандартные установочные тесты для проверки
корректной установки Системы.
R15.1.2
Поставщик должен предложит в рамках M
технического предложения список тестов,
условий испытаний, критериев успеха и
другого для испытаний Системы.
R15.1.4
Поставщик Системы проведет поэтапные M
детальные испытания, в том числе тесты
производительности,
времени
отклика,
пропускной способности, Системы совместно с
организацией, уполномоченной Покупателем,
согласно
тестам
предоставленным
Поставщиком.
R15.1.5
Поставщик должен провести демонстрацию М
Системы
с
участием
представителей
568
Раздел VI. Технические требования
Покупателя и организацией, уполномоченной
Покупателем согласно сценарию испытаний
Системы на любом этапе контракта.
R15.1.6
Поставщик должен оформить результаты М
демонстрации в виде Протокола о проведении
демонстрации по форме, согласованной с
Покупателем. Протокол должен быть подписан
всеми участниками демонстрации.
Место
проведение
демонстрации
согласовываются
с
Покупателем
и
организацией уполномоченной Покупателем.
R15.1.7
Поставщик должен устранять замечания, М
полученные в ходе проведения демонстраций,
и проводить повторные демонстрации до
получения протокола об успешном проведении
демонстрации.
Сроки устранения замечаний согласовываются
с Покупателем.
R15.1.8
Тестирование должно осуществляться в М
соответствии с одним из стандартов IEEE
829/1009, BS 7925, ISO/AS 9100 и
разработанным документом «Программа и
методика испытаний» СТ РК 1089-2002.
R15.1.9
Поставщик должен протестировать Систему в М
соответствии с Web Content Accessibility
569
Раздел VI. Технические требования
Guidelines (WCAG) 2.0. Поставщик должен
представить подробную информацию о
результатах тестировании.
R15.1.10
Поставщик должен протестировать Систему по М
безопасности в соответствии с OWASP Топ 10
уязвимости. Поставщик должен представить
подробную
информацию
о
результатах
тестировании.
R15.1.11
Поставщик должен согласовать с Покупателем М
сценарий тестирования и предоставить отчёт по
результату каждого тестирования.
R15.2
Приемка в эксплуатацию
R15.2.1
Акт приемки Системы подписывается на M
основании
бесперебойной
работы
при
нормальных условиях эксплуатации для
Системы в течении 3 месяцев. В случае
выявления ошибок функционирования в
данный период Поставщик должен внести
необходимые изменения и провести повторную
эксплуатацию Системы в течении 3 месяцев.
Под ошибками функционирования понимаются
критические ошибки, которые не позволяют
эксплуатировать Систему
R15.2.2
Поставщик должен начать необходимую M
работу для устранения дефектов или
570
Раздел VI. Технические требования
571
повреждений в течение 10 рабочих дней для
некритичных ошибок. Для критических ошибок
поставщик
должен
начать
работу,
необходимую для устранения дефектов или
повреждений в течение 3 рабочих дней,
обеспечить фиксацию времени и отчет о
фиксации хода каждый час в течение
оперативного, а также гарантийного срока.
Критические ошибки: система не работает или
работает
не
стабильно.
Важная
функциональная составляющая не работает или
недоступна. Потеря данных или прерывание
основного потока процесса. Компонент
системы
непригоден
из-за
сбоя
или
неправильной
функциональности.
Пользователи не могут выполнять любую
работу.
R16
Требования к обеспечению
стороны Покупателя
контроля
со
R16.1
Поставщик
должен
с
периодичностью, М
определенной в план-графике, предоставлять
Покупателю отчет о проделанной работе за
истекший период.
R16.2
Отчет должен содержать информацию о М
выполненных работах Поставщика за отчетный
период, в соответствии с утвержденным планграфиком, включая услуги по гарантийной
Раздел VI. Технические требования
поддержке, по СТП с приложением всей
утвержденной в процессе реализации договора
за отчетный период документации, включая
официальную переписку, в бумажном и
электронном виде (в формате pdf).
R16.3
Отчет должен быть согласован с организацией, М
уполномоченной Покупателем.
R16.4
Покупатель может в любой момент исполнения М
договора проводить контроль исполнения
Поставщиком мероприятий и качества услуг по
договору.
572
Раздел VI. Технические требования
573
H. ПРИЛОЖЕНИЯ
Приложение 1
О Республиканском координационном центре по трансплантации
1.
Учреждение
«Республиканский
координационный
центр
по
трансплантации» создано во исполнение Плана мероприятий по реализации
Государственной программы развития здравоохранения Республики Казахстан
«Саламатты Казахстан» на 2011-2015 годы, утвержденного постановлением
Правительства Республики Казахстан от 29 января 2011 года № 41, с целью
организации эффективных мероприятий по предтрансплантационной подготовке, в
том числе по изъятию и распределению тканей и (или) органов (части органов) в
государственные организации здравоохранения, осуществляющих деятельность по
специальности «трансплантология» в соответствии с лицензией.
2.
В настоящем документе используются следующие основные понятия:
1)
трансплантационная координация - организация мероприятий по
получению и управлению информацией о наличии потенциальных доноров и
реципиентов, а также изъятию, консервации, распределению и транспортировке
тканей и (или) органов (части органов) в трансплантационные центры после
получения результатов совместимости «донор - реципиент»;
2)
трансплантационный
центр
организация
здравоохранения,
осуществляющая деятельность по специальности «трансплантология» в соответствии
с лицензией;
3)
донорский стационар - организация здравоохранения, в которой
проводится изъятие ткани и (или) органов (части органов) у трупного донора;
бригада по изъятию органов - группа профильных специалистов по
изъятию ткани и (или) органов (части органов) оперативным путем у трупного донора
в целях трансплантации;
4)
Лист ожидания реципиентов - информационная база данных о
реципиентах, нуждающихся в трансплантации ткани и (или) органов (части органов);
5)
6)
Реестр доноров ткани и (или) органов (части органов) информационная база данных о лицах, изъявивших прижизненное согласие на изъятие
у них после смерти ткани и (или) органов (части органов) в целях трансплантации;
исследования иммунологического типирования тканей - исследование
крови с целью выявления антигенов тканевой совместимости (human leucocyte
antigens);
7)
кросс-матч реакция - измерение уровня антител крови реципиента и
антигенов, расположенных на поверхности клеток потенциального донора.
Перекрестное типирование лимфоцитов донора и сыворотки реципиента.
8)
В своей работе РКЦТ руководствуется Конституцией Республики
Казахстан, Кодексом Республики Казахстан «О здоровье народа и системе
здравоохранения», нормативными правовыми актами Республики Казахстан.
3.
Раздел VI. Технические требования
574
Основные задачи и функции РКЦТ
Основной задачей РКЦТ является обеспечение и проведение
оперативных мероприятий по созданию эффективной системы донорства тканей и
(или) органов (части органов) в Республике Казахстан с целью трансплантации и
спасения жизни, а также восстановления здоровья граждан, предупреждения
незаконной торговли тканями и (или) органами (частями органов) человека.
1.
2.
Основными функциями РКЦТ являются:
обеспечение быстрого и качественного процесса пересадки ткани и
(или) органов (части органов) от момента обнаружения потенциального донора до
трансплантации органов от этого донора реципиенту;
1)
координация мероприятий по изъятию, консервации, распределению и
транспортировке тканей и (или) органов (части органов) для трансплантации в
трансплантационные центры;
2)
3)
организация обучения лиц, осуществляющих трансплантационную
координацию, а также медицинских работников донорских стационаров по вопросам
законодательства Республики Казахстан в области трансплантологии, донорскому
менеджменту, общения с родственниками потенциального донора, констатации
смерти человека на основании необратимой гибели головного мозга;
4)
ведение и актуализация Листа ожидания реципиентов, а также Реестра
доноров ткани и (или) органов (части органов);
мониторинг использования донорских тканей и (или) органов (части
органов) в трансплантационных центрах, в том числе регистрация и анализ
осложнений и побочных реакций;
5)
участие в организации и реализации информационно-просветительских
программ в средствах массовой информации, взаимодействие с представителями
религиозных конфессий по пропаганде донорства тканей и (или) органов (части
органов) среди населения Республики Казахстан;
6)
7)
взаимодействие с государственными органами, неправительственными
и международными организациями по вопросам донорства и трансплантации тканей и
(или) органов (части органов) в Республике Казахстан;
8)
представление предложений уполномоченному органу в области
здравоохранения по совершенствованию нормативных правовых актов в области
трансплантации тканей и (или) органов (части органов);
9)
подготовка и проведение республиканских семинаров, симпозиумов и
конференций, а также участие в республиканских и международных конференциях по
вопросам органного донорства и трансплантации тканей и (или) органов (части
органов).
Организация деятельности РКЦТ
3.
РКЦТ организует свою деятельность в соответствии со Схемой
Раздел VI. Технические требования
575
взаимодействия медицинских организаций по трансплантации тканей и (или) органов
(части органов) в Республике Казахстан, согласно приложению 4 к настоящему
приказу № 199 от 29.03.2013г. «О мерах по развитию службы трансплантации
органов и тканей в Республике Казахстан» (с изменениями и дополнениями на
13.08.2013г.)
РКЦТ взаимодействует с донорскими стационарами в части
организации оперативного изъятия ткани и (или) органов (части органов) у трупного
донора и трансплантационными центрами по проведению реципиенту трансплантации
тканей и (или) органов (части органов), а также обеспечивает экстренный выезд
бригад по изъятию органов.
4.
Республиканский координационный центр санитарной авиации
обеспечивает своевременную транспортировку бригад по изъятию органов, а также
тканей и (или) органов (части органов) по экстренному вызову, поступившему с
РКЦТ.
5.
6.
РКЦТ тесно взаимодействует с организациями здравоохранения,
осуществляющих деятельность в сфере службы крови по вопросам проведения
исследования иммунологического типирования тканей, кросс-матч реакции донорам
тканей и (или) органов (части органов) и реципиентам, а также с лабораторией
инфекционного контроля.
7.
Трансплантационная координация осуществляется сотрудником РКЦТ,
имеющим медицинское образование, функциями которого являются:
получение от регионального трансплантационного координатора
первичной информации о наличии потенциального донора в определенном донорском
стационаре;
1)
принятие решения совместно с региональным трансплантационным
координатором о характере изъятия тканей и (или) органов (части органов) от
трупного донора;
2)
информирование трансплантационных центров о возможности и
характере изъятия тканей и (или) органов (части органов) от трупного донора;
3)
4)
распределение (до начала изъятия) тканей и (или) органов (части
органов) и подбор реципиентов с учетом контроля результатов исследования
иммунологического типирования тканей и кросс-матч реакции «донор-реципиент»;
организация вызова и направление в донорский стационар бригады по
изъятию органов;
5)
6)
организация вызова реципиента на трансплантацию тканей и (или)
органов (части органов), при необходимости - организация его дополнительного
клинико-лабораторного обследования;
7)
ведение и актуализация Листа ожидания реципиентов и Реестра доноров
ткани и (или) органов (части органов);
ведение хронометража времени с момента изъятия от донора тканей и
(или) органов (части органов) до трансплантации реципиенту.
8)
Раздел VI. Технические требования
576
Руководители донорских стационаров обеспечивают круглосуточное
информирование РКЦТ о наличии донора через региональных трансплантационных
координаторов.
8.
Функциями медицинского работника, осуществляющего региональную
трансплантационную координацию являются:
9.
1)
выявление потенциального донора тканей и (или) органов (части
органов)
при
тесном
сотрудничестве
с
персоналом
отделений
анестезиологии/реанимации, неврологии, нейрохирургии и других;
взаимодействие с супругом (супругой), близкими родственниками или
законными представителями потенциального донора с целью получения согласия на
изъятие тканей и (или) органов (части органов) для последующей трансплантации
реципиентам;
2)
3)
своевременная передача в РКЦТ информации (по телефонной связи) о
возможности изъятия ткани и (или) органов (части органов) у трупного донора при
получении согласия от его близких родственников;
4)
информирование руководителя донорского стационара или лица его
замещающего о наличии потенциального донора органов и возможности изъятия его
тканей и (или) органов (части органов) для последующей трансплантации
реципиентам;
обеспечение участия судебно-медицинского эксперта и (или) врачапатологоанатома в процессе изъятия тканей и (или) органов (части органов) от
трупного донора;
5)
организация направления биологического материала потенциального
донора ткани и (или) органов (части органов) в лабораторию на выявление
трансфузионных инфекций (ВИЧ, вирусные гепатиты В и С, сифилис,
цитомегаловирусная инфекция), а также на исследования иммунологического
типирования тканей и кросс-матч реакцию;
6)
ведение статистической отчетности по учету доноров для изъятия ткани
и (или) органов (части органов).
7)
10.
Трансплантационные центры обеспечивают ведение мониторинга
состояния реципиентов до- и после оперативного вмешательства, а также
своевременное их обследование.
11.
В трансплантационных центрах создаются хирургические бригады по
изъятию органов, которые работают в круглосуточном режиме.
12.
РКЦТ возглавляет руководитель с профессиональным медицинским
образованием, имеющий сертификат специалиста по «Социальной гигиене и
организации здравоохранения», назначаемый на должность и освобождаемый от
должности по согласованию с уполномоченным органом в области здравоохранения.
13.
Руководитель РКЦТ выполняет следующие функции:
1)
обеспечивает реализацию РКЦТ функций, установленных настоящим
Положением;
Раздел VI. Технические требования
577
представляет уполномоченному органу в области здравоохранения
Республики Казахстан ежеквартально отчет о деятельности РКЦТ;
2)
3)
осуществляет иные функции, предусмотренные законодательством
Республики Казахстан.
14.
Трансплантационная координация осуществляется в круглосуточном
режиме.
Региональные отделения РКЦТ создаются в областных центрах и /или
городах республиканского значения, где имеются более одной государственной
организации здравоохранения, осуществляющей деятельность по специальности
«трансплантология» в соответствии с лицензией.
15.
16.
Финансирование
республиканского бюджета.
РКЦТ
осуществляется
за
счет
средств
Рекомендуемые кадровый состав и материально-техническая база РКЦТ
Рекомендуется следующий кадровый состав: 2 заместителя директора, 5
республиканских
трансплантационных
координаторов,
16
региональных
трансплантационных координаторов, 64 стационарных трансплантационных
координаторов, юрист, системный администратор и второстепенные службы.
17.
18.
Рекомендуемая материально-техническая база:
Раздел VI. Технические требования
578
Рис. А1. Схема взаимодействия медицинских организаций по трансплантации
тканей и (или) органов (части органов) в Республике Казахстан
Раздел VI. Технические требования
579
Приложение 1-1
ФОРМА
УЧЕТА ЛИЦА, НУЖДАЮЩЕГОСЯ В ТРАНСПЛАНТАЦИИ СЕРДЦА
Рег. №. _______
«___»__________201__г.
Сведения о враче-кардиологе, к которому прикреплен пациент
Должность
Телефон рабочий
Телефон
мобильный
Отчество
e-mail
Наименование медицинской организации
Общие сведения о пациенте
Фамилия
ИИН
Имя
Национальность
Отчество
Дата рождения
(дд/мм/гггг)
Пол
Возраст
Дата постановки на
Статус ургентности
учет
Социальный статус: 1 - служащий, 2 рабочий, 3 - работник сельского
хозяйства, 4 - пенсионер, 5 - учащийся, 6
- домохозяйка, 7 - лицо, занятое
индивидуальным трудом, 8 - служитель
культа, 9 - безработный, 10 - прочее.
ИИН
Фамилия
Имя
Категория льготности: инвалид Великой
Отечественной войны - 1, участник
Великой Отечественной войны - 2, воининтернационалист - 3, инвалид детства 4, инвалид по заболеванию - 5, лица,
подвергшиеся радиации - 6, лица,
приравненные к УВОВ – 7, призывник 8, инвалид труда - 9, переселенцы - 10,
прочие - 99.
Фамилия
Имя
e-mail
Область
Контактное лицо пациента
Мобильный телефон
Домашний телефон
Рабочий телефон
Адресные данные пациента
Адрес прописки
Район
Наименование
Улиц
Дом
Квартира
Раздел VI. Технические требования
580
населенного пункта
Область
Район
Адрес проживания
Наименование
населенного пункта
а
Улиц
а
Дом
Мобильный телефон
Домашний телефон
Рабочий телефон
e-mail
Данные обследования пациента
Диагноз (основной)
Наименование
Код МКБ-10
Дополнительные диагнозы
№ п.п.
Код МКБ-10
Наименование
Группа крови
Rh фактор
RW
ВИЧ
Дата сдачи
сыворотки крови
A
B
А
А
A*
B*
ИФА
IgM
ToxoIgM
HBsAg
HBcAg
HBeAg
Рост
Вес
BMI
BSA
Контрольный срок
следующей сдачи
сыворотки
HLA-типирование (среднее разрешение)
Cw
Dw
HLA-типирование серологическим методом (среднее разрешение)
В
Cw
HLA-типирование молекулярным методом (среднее разрешение)
В
DRB1
HLA-типирование (высокое разрешение)
DRB1*
DRQB1*
% сенсибилизации
Серология
ЦМВ
IgG
Токсоплазмоз
ToxoIgG
Гепатит В
aHBs
aHBcIgG
aHBcIgM
Гепатит C
Квартира
Раздел VI. Технические требования
HCV total
EBV IgM
HSV IgM
Ао мах
ЛЖ мах
ЛА мах*
Пжмах
ПП мах
НПВ мах
АД сист
SatO2
PVR (Wood)*
ЧСС
КДО
Креатинин
Общий билирубин
АЛТ
МНО
ТТГ
Т4 св
Гемоглобин
Тромбоциты
Креатинин
НЛА, сенсит %
ДЛА мах*
aHCVIgM
aHCVIgG
Вирус Эбштейна -Барра (ВЭБ)
EBV IgM
Вирус простого герпеса
HSV IgG
CVP
Зондирование
Ао мин
Ао сред
ЛЖ мин
КДД ЛЖ
ЛА мин
ЛА сред
ПЖ мин
ПЖ сред
ПП мин
ПП сред
НПВ мин
НПВ сред
АД диас
SatO2 ПП
CO*
ДЗЛК
ЭхоКГ
КДР
ФВ ЛЖ
Лабораторные исследования
Мочевина
Прямой билирубин
АСТ
Глюкоза крови
Т3 св
Ат к ТПО
Лейкоциты
ProBNP
Мочевина
ФВ ЛЖ %
PVR (W)
Примечания
581
Раздел VI. Технические требования
582
Приложение 1-2
ФОРМА
УЧЕТА ЛИЦ, НУЖДАЮЩИХСЯ В ТРАНСПЛАНТАЦИИ ПЕЧЕНИ
Рег. №. _______
«___»__________201__г.
ИИН
Фамилия
Имя
Отчество
Наименование медицинской
организации
Фамилия
Имя
Отчество
Пол
Дата внесения в ЛО
Сведения о лечащем враче
Должность
Телефон рабочий
Телефон мобильный
e-mail
Общие сведения о пациенте
ИИН
Национальность
Дата рождения
(дд/мм/гггг)
Возраст
Степень ургентности
(класс неотложности)
Причина смерти
Дата смерти
Медицинская организация
прикрепления
Социальный статус: 1 - служащий, 2 - рабочий, 3 - работник
сельского хозяйства, 4 - пенсионер, 5 - учащийся, 6 домохозяйка, 7 - лицо, занятое индивидуальным трудом, 8 служитель культа, 9 - безработный, 10 - прочее.
Категория льготности: инвалид Великой Отечественной войны
- 1, участник Великой Отечественной войны - 2, воининтернационалист - 3, инвалид детства - 4, инвалид по
заболеванию - 5, лица, подвергшиеся радиации - 6, лица,
приравненные к УВОВ – 7, призывник - 8, инвалид труда - 9,
переселенцы - 10, прочие - 99.
Фамилия
Имя
e-mail
Область
Контактное лицо пациента
Мобильный телефон
Домашний телефон
Рабочий телефон
Адресные данные пациента
Адрес прописки
Наименование
Район
Улица
населенного пункта
Дом
Квартира
Раздел VI. Технические требования
Область
Мобильный телефон
Домашний телефон
Район
583
Адрес проживания
Наименование
населенного пункта
Улица
Дом
Рабочий телефон
e-mail
Данные обследования пациента
Диагноз, являющийся
основанием для
Код МКБ-10
Наименование
трансплантации
Диагноз, являющийся
причиной печеночной Наименование
Код МКБ-10
недостаточности
Дополнительные диагнозы
№ п.п.
Код МКБ-10
Наименование
Группа крови
Rh фактор
Окружность
живота
RW
ВИЧ
Уровень PRA
(%)методом ИФА
Уровень PRA
(%)методом
серологии
Рост
Вес
Окружность
грудной
клетки
Наличие
варикознорасширенных
вен пищевода
Маркеры вирусных
гепатитов
Сведения о наличии
вакцинации ВГ
Дата забора анализа
на определение
уровня PRA
(%)методом ИФА
Дата забора анализа
на определение
уровня PRA
(%)методом
серологии
Общий Билирубин
(мкмоль/л)
Специфичность АТ ан
1 класс HLA методом
ИФА
HLA-типирование серологическим методом (среднее разрешение)
A
B
Cw
HLA-типирование молекулярным методом (среднее разрешение)
Квартира
Раздел VI. Технические требования
A
Кросс-матч
584
B
DRB1
Кросс-матч
Дата забора
ИИН предполагаемого донора
Предполагаемый трансплантационный
центр
Резервный трансплантационный центр
Предполагаемая трансплантация (от живого
человека и кадавра)
Наличие донора
Информация о трансплантации
Вид трансплантации ИИН донора
Дата
Наименование медицинской
трансплантации
организации, в которой произведена
трансплантация
Раздел VI. Технические требования
585
Приложение 1-3
ФОРМА
УЧЕТА ЛИЦ, НУЖДАЮЩИХСЯ В ТРАНСПЛАНТАЦИИ ПОЧКИ
Рег. №. _______
«___»__________201__г.
ИИН
Фамилия
Имя
Отчество
Наименование медицинской
организации
Сведения о лечащем враче
Должность
Телефон рабочий
Телефон мобильный
e-mail
Общие сведения о пациенте
ИИН
Национальность
Дата рождения
(дд/мм/гггг)
Пол
Возраст
Дата внесения в ЛО
Степень ургентности
(класс неотложности)
Поликлиника
Дата начала
прикрепления
гемодиализа
Дата смерти
Причина смерти
Медицинская организация прикрепления
Социальный статус: 1 - служащий, 2 - рабочий, 3 - работник
сельского хозяйства, 4 - пенсионер, 5 - учащийся, 6 домохозяйка, 7 - лицо, занятое индивидуальным трудом, 8 служитель культа, 9 - безработный, 10 - прочее.
Категория льготности: инвалид Великой Отечественной войны
- 1, участник Великой Отечественной войны - 2, воининтернационалист - 3, инвалид детства - 4, инвалид по
заболеванию - 5, лица, подвергшиеся радиации - 6, лица,
приравненные к УВОВ – 7, призывник - 8, инвалид труда - 9,
переселенцы - 10, прочие - 99.
Фамилия
Имя
Отчество
Фамилия
Имя
e-mail
Область
Контактное лицо пациента
Мобильный телефон
Домашний телефон
Рабочий телефон
Адресные данные пациента
Адрес прописки
Наименование
Район
Улица
населенного пункта
Дом
Квартира
Раздел VI. Технические требования
Область
Мобильный телефон
Домашний телефон
Район
586
Адрес проживания
Наименование
населенного пункта
Улица
Дом
Квартира
Рабочий телефон
e-mail
Данные обследования пациента
Диагноз (являющийся
основанием для
Наименование
Код МКБ-10
трансплантации)
Диагноз (основной,
являющийся
Наименование
Код МКБ-10
причиной ТХПН)
Дополнительные диагнозы
№ п.п.
Код МКБ-10
Наименование
Группа крови
Rh фактор
RW
ВИЧ
Уровень PRA
(%)методом ИФА
Уровень PRA
(%)методом
серологии
Рост
Вес
Маркеры вирусных
гепатитов
Сведения о наличии
вакцинации ВГ
Дата забора анализа
на определение
уровня PRA
(%)методом ИФА
Дата забора анализа
на определение
уровня PRA
(%)методом
серологии
Специфичность АТ ан 1 класс HLA методом
ИФА
HLA-типирование серологическим методом (среднее разрешение)
A
B
Cw
HLA-типирование молекулярным методом (среднее разрешение)
A
B
DRB1
Кросс-матч
Кросс-матч
Дата забора
ИИН предполагаемого донора
Раздел VI. Технические требования
587
Предполагаемый трансплантационный
центр
Резервный трансплантационный центр
Предполагаемая трансплантация (от живого
человека и кадавра)
Наличие донора
Информация о трансплантации
Вид трансплантации ИИН донора
Дата
Наименование медицинской
трансплантации
организации, в которой произведена
трансплантация
Раздел VI. Технические требования
588
Приложение 2
ФОРМА
РЕГИСТРАЦИИ ДОНОРА
Рег. №. _______
«___»__________201__г.
Сведения о лице, заполняющим форму
ИИН
Должность
Фамилия
Телефон рабочий
Имя
Телефон мобильный
Отчество
e-mail
Наименование медицинской организации
Возможный донор
№ истории болезни
Пол
Дата рождения
Возраст
(дд/мм/гггг)
Дата поступления
(дд/мм/гггг)
Наименование
Диагноз (основной)
Код МКБ-10
Дополнительные диагнозы
№ п.п.
Код МКБ-10
Наименование
Примечание (в т.ч.: умер, переведен в
отделение, отказ родственников и др.)
Потенциальный донор
Дата поступления в ОРИТ
Период нахождения в
ОРИТ
Группа крови
Rh фактор
Дата констатации СМ/необратимости остановки кровообращения
Мероприятия по
согласие родственников
кондиционированию
на изъятие органов/
прижизненное согласие
Примечание (в т.ч.: умер, переведен в
отделение, отказ родственников и др.)
Список органов/тканей, которые предполагается изъять
№ п.п.
Наименование
Примечание
ИИН
Фамилия
Примечание (в т.ч.: умер, переведен в
Актуальный донор
Имя
Отчество
Раздел VI. Технические требования
отделение, отказ родственников и др.)
Список органов/тканей, которые предполагается изъять
№ п.п.
Наименование
Примечание
589
Раздел VI. Технические требования
590
Приложение 2-1
ФОРМА
УЧЕТА ДОБРОВОЛЬНОГО ДОНОРА
Рег. №. _______
«___»__________201__г.
Сведения о лице, подающем заявку
Должность
Телефон рабочий
Телефон
мобильный
Отчество
e-mail
Наименование медицинской организации
Общие сведения о пациенте
Фамилия
ИИН
Имя
Национальность
Отчество
Дата рождения
(дд/мм/гггг)
Пол
Возраст
Медицинская организация прикрепления
Социальный статус: 1 - служащий, 2 - рабочий, 3 - работник
сельского хозяйства, 4 - пенсионер, 5 - учащийся, 6 домохозяйка, 7 - лицо, занятое индивидуальным трудом, 8 служитель культа, 9 - безработный, 10 - прочее.
Категория льготности: инвалид Великой Отечественной войны
- 1, участник Великой Отечественной войны - 2, воининтернационалист - 3, инвалид детства - 4, инвалид по
заболеванию - 5, лица, подвергшиеся радиации - 6, лица,
приравненные к УВОВ – 7, призывник - 8, инвалид труда - 9,
переселенцы - 10, прочие - 99.
Документ, удостоверяющий личность
Тип
документа
Номер
Кем выдан
Когда выдан
(паспорт, уд.
личности)
ИИН
Фамилия
Имя
Фамилия
Имя
e-mail
Область
Контактное лицо пациента
Мобильный телефон
Домашний телефон
Рабочий телефон
Адресные данные пациента
Адрес прописки
Район
Наименование
Улица
Действителе
н до
Дом
Квартира
Раздел VI. Технические требования
591
населенного пункта
Область
Район
Адрес проживания
Наименование
населенного пункта
Улица
Дом
Квартира
Мобильный телефон
Домашний телефон
Рабочий телефон
e-mail
Данные обследования пациента*
Группа крови
Рост
Rh фактор
Вес
RW
Маркеры вирусных гепатитов
ВИЧ
Сведения о наличии вакцинации
ВГ
HLA-типирование серологическим методом (среднее разрешение)
A
B
Cw
HLA-типирование молекулярным методом (среднее разрешение)
A
B
DRB1
Кросс-матч
Кросс-матч
Дата забора
ИИН предполагаемого
реципиента
Дата регистрации
Дата смерти
Тип согласия на использование органов/части органов и/или тканей **
(согласие на прижизненное использование для родственника с
указанием конкретного лица, согласие на прижизненное использование
при жизни любому лицу из ЛО, согласие на посмертное использование
любому лицу из ЛО)
Список органов/части органов и/или тканей
Вид трансплантации
Наименование органа/части
ИИН предполагаемого
органа и/или ткани
реципиента
Примечание
*должна быть прикреплена сканированная копия выписки, выданная не позже 1
месяца со дня регистрации, содержащая следующую информацию:
Раздел VI. Технические требования
592
− Рост
− вес
− Группа крови
− Резус -фактор
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
Отсутствие онкологических заболеваний;
Отсутствие активного туберкулеза;
Определение группы крови по системе АВО и резус принадлежности
Общий анализ крови
Общий анализ мочи
Определение концентрации общего белка, альфа и гамма-глобулинов
Определение альбумина
Определение билирубина
Определение креатинина
Определение глюкозы
Определение мочевины
Определение альбумин, Ca, Mg, P
Определение уровня активности ГГТП
Определение уровня активности ЩФ
Определение концентрации электролитов крови ( К,Na, Ca, Cl)
Определение параметров КОС
Определение активности АлАТ
Определение уровня активности АсАТ
Определение панкреатической амилазы
Определение липидного спектра
Исследование
показателей
гемостаза:
aPPT,
ACT,
определение
активированного частичного тромбопластинового времени, протромбинового
времени, международного нормализованного отношения, тромбинового
времени, определение концентрации фибриногена и растворимых фибринмономерных комплексов, д-димеров, антитромбина III, Протеинов «С» и
«S»,при наличии реактивов.
ИФА anti CMV (IgM+G)$,при наличии реактивов.
ИФА на маркеры Вич-инфекции (antiHIV и HIV Ag);
HLA типирование 1 класса (HLA-A,B) и II класса (HLA-DR);
Определение предшествующих HLA антител
ИФА на HBsAg и суммарные антитела к core-антигену HBV;
Полимеразно-цепная реакция (ПЦР) на HBV-DNA (при положительном
HBsAg);
ИФА на антитела к HBc Ig класса М и суммарные Ig (при положительном
HBsAg);
ИФА на HBeAg (при положительном HBsAg);
ИФА на anti-HBe (при положительном HBsAg);
ИФА на Anti-HDV IgM,G (при положительном HBsAg);
ПЦР на HDV-DNA (при положительном ИФА на anti-HDV);
ИФА на anti-HCV;
ПЦР на HCV-RNA (при положительном ИФА на anti-HCV);
ИФА на EBV IgM;}
Раздел VI. Технические требования
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
593
ИФА на EBV IgG;} при наличии реактивов
ИФА на CMV IgM;}
ИФА на CMV IgG;}
ИФА на HIV-Ag и ИФА на anti-HIV;
ИФА на HIV-RNA при положительной ИФА на anti-HIV
Комплекс серологических реакций на сифилис (anti-T/pallidum, RW)
Бактериологическое исследование слизистых оболочек зева, носа и влагалища;
мочи; кала ( на носительство сальмонелл, шигелл, золотистого ставилококка ,
грибов), мокроты при ее наличии.
Электрокардиография (ЭКГ)
Рентгенография грудной клетки
УЗИ сердца (эхокардиография)
УЗИ ОБП
Спирография (по показаниям)
Рентгенография орагнов грудной полости
Фиброгастродуоденоскопия (ФГДС)
Ретроградная( РХГ) или МР (магнитнорезонансная)- холангиография (по
показаниям)
Колоноскопия (по показаниям)
Компьютерная томографии многосрезовая (мультислайс КТ-64)- трехфазное
ангиографическое исследование органов брюшной полости
КТ грудной клетки (по показаниям)
КТ головного мозга
Определение онкомаркера- альфа-фетопротеин (АФП)
Определение онкомаркера СА-19-9
Определение ракового эмбрионального антигена (РЭА)
Определение простат-специфического антигена(по показаниям)
Допплерография печени и почек
Биопсия печени
Диагностика ферментопатий
Определение антимитохондриальных антител (АМА М2)
Определение антинуклеарных антител (ANA)
Определение антинейтрофильных антител (ANCA)
Определение антител к микросомам печени и почек (anti LKM-1),при
наличии реагентов
Глюкозотолерантный тест (по показаниям)
Консультация врача-терапевта}
Консультация врача-кардиолога} при наличии данных специалистов в
стационаре
Консультация врача-гастроэнтеролога}
Консультация врача-оториноларинголога
Консультация врача-психотерапевта
Консультация врача-инфекциониста, при наличии данных специалистов в
стационаре
Консультация врача-иммунолога
Консультация врача-гематолога
Консультация врача-эндокринолога
Раздел VI. Технические требования
594
− Консультация врача-хирурга, врача-трансплантолога
− Консультация врача-анестезиолога-реаниматолога
**должна быть прикреплена
письменного волеизъявления
сканированная
копия
нотариально
заверенного
Раздел VI. Технические требования
595
Приложение 3
Таблица критериев для выбора потенциального реципиента из «Листа
ожидания»
Критерий
Подсчет баллов
9 баллов за полную совместимость по А,В,Cw,DRB1
HLAсовместимость
7 баллов за полную совместимость по В или DRB1
5 баллов за несовместимость по одному антигену В или
DRB1
2 балла за несовместимость по двум антигенам В или
DRB1
Предсуществующие 4 балла за более 80% и отрицательную перекрестную
антитела
пробу
Возраст
4 балла пациенту не старше 40 лет
3 балла пациенту от 41 до 63 лет
По решению консилиума врачей
Ургентность
При равных при прочих условиях приоритет жителям
региона непосредственного действия конкретного
трансплантологического центра
1 балл совместимому по группе крови пациенту с
наиболее продолжительным сроком ожидания
Продолжительность
ожидания
1 дополнительный балл за каждый следующий год
пребывания в "Листе ожидания"
1 дополнительный балл, если пациент в прошлом донор
органа
Раздел VI. Технические требования
596
Приложение 4
*КПД
**КЭД
***КЭТК
примечания
коэффициент эффективности
трансплантационной координации ***
коэфициент эффективности донорства **
коэфициент потенциального донорства*
Количество проведенных родственных
трансплантаций
Количество проведенных неродственных
трансплантаций
кол-во актуальных
доноров
кол-во потенциальных
доноров
кол-во возможных
доноров
общее кол-во
умерших в ОРИТ
кол-во умерших
в ОРИТ за 1-7-е сутки
наименование МО
Отчет ежемесячный врача-координатора
коэфициент потенциального донорства (отношение кол-ва умерших в 1-7-е
сутки к общему кол-ву умерших в ОРИТ*100)
коэфициент эффективности донорства (отношение кол-ва актуальных
доноров к кол-ву умерших в 1-7-е сутки*100)
коэффициент эффективности трансплантационной координации
(отношение КЭД к КПД)
Итого:
Кол-во летальных случаев
Кол-во аллогенных
трансплантаций поджелудочной
железы, островков Лангерганса
Кол-во аллогенных
трансплантаций сердца
Кол-во неродственных
аллогенных трансплантаций
печени
Кол-во родственных аллогенных
трансплантаций печени
Кол-во неродственных
аллогенных трансплантаций
почек
Кол-во родственных аллогенных
трансплантаций почек
Юридическое название МО
Регион
Раздел VI. Технические требования
597
Приложение 5
Отчет о проведенных аллогенных трансплантаций органов
№
Перечень изъятых органов
Дата эксплантации органов
возраст
ПОТЕНЦИАЛЬНЫЙ
донор
ИИН
Мероприятия по кондиционированию
согласие родственников на изъятие
органов, прижизненное согласие
ФИО
период нахождения в ОРИТ
группа крови и резус-фактор
пол
ВОЗМОЖНЫЙ
донор
возраст
диагноз (с кодом МКБ)
дата поступления
Возраст
диагноз (с кодом МКБ)
№ истории болезни
Наименование МО (юридическое название)
Раздел VI. Технические требования
598
Приложение 6
Ежедневный отчет регионального трансплантационного координатора
АКТУАЛЬНЫЙ
донор
Примечан
ие (в т.ч.:
умер,
переведен
в
отделение
,отказ
родствеен
иков и
др.)
Раздел VI. Технические требования
599
Приложение 7
Прогнозируемое количество пользователей системы по модулям
№
Требование
1
Модуль «Регистрация лица, нуждающегося в трансплантации» – 133
пользователей.
2
Модуль
«Стационарный
пользователей
3
Модуль «Лабораторные исследования» – 2 пользователей
4
Модуль «Региональный
пользователей
5
Модуль «Республиканский трансплантационный координатор»
пользователей
6
Модуль «Трансплантационная бригад» – 10 пользователь
7
Модуль «Мониторинг состояния
трансплантация» – 21 пользователей
8
Модуль «Формирование аналитических и статистических таблиц»
пользователей
9
Модуль «Администрирование» – 3 пользователей
трансплантационный
трансплантационный
лиц,
координатор»
координатор»
которым
была
–
19
–
16
– 6
произведена
– 21
Раздел VI. Технические требования
600
Раздел VII. Образцы форм
РАЗДЕЛ VII. ОБРАЗЦЫ ФОРМ
601
Раздел VII. Образцы форм
602
Пояснения по работе с Образцами форм, предназначенные для
Участников торгов
Покупатель подготовил формы, представленные в настоящем разделе
Документации для торгов, с учетом конкретных требований закупаемой Системы. В их
основе лежат формы, содержащиеся в Типовой документации для торгов, которая
составлена Всемирным банком для случаев поставки и установки Информационных
систем. Участники торгов должны использовать эти формы (или формы, где
аналогичная, по существу, информация представлена в той же последовательности) в
своих конкурсных предложениях. Участники торгов не должны вносить в них
изменения без предварительного письменного согласия Покупателя (для чего может
также потребоваться разрешение Всемирного банка). Если у Участника торгов
возникнет вопрос, касающийся смысла или необходимости информации,
содержащейся в этих формах, или их формата, и/или приведенных в них инструкций,
этот вопрос нужно в кратчайшие сроки довести до сведения Покупателя на этапе
разъяснения конкурсных предложений либо в ходе предтендерного совещания, либо в
виде письменного запроса Покупателю, направленного в соответствии со Статьей ИУТ
10.
Покупатель постарался дать пояснительный текст и инструкции, чтобы
Участники торгов смогли подготовить эти формы точно и в полном объеме.
Инструкции, изложенные непосредственно в самих формах, выделены с помощью
типографских приемов (например, курсив, заключенный в квадратные скобки), как это
показано на приведенном ниже примере, взятом из формы Конкурсного предложения:
Имеющий надлежащие полномочия на подписание настоящего конкурсного
предложения от имени и по поручению [указать наименование Участника торгов]
В процессе подготовки своего конкурсного предложения Участник торгов
должен проследить за тем, чтобы были представлены все подобные сведения и сняты
использованные типографские приемы.
Образцы форм представляют собой типовой набор документов,
сопровождающих процесс закупок по мере его перехода от этапа торгов к этапу
подготовки, а затем выполнения Контракта. Первый набор форм заполняется и
включается в состав конкурсного предложения до истечения срока подачи
предложений. К ним относятся: (i) форма Конкурсного предложения; (ii) Таблицы цен;
(iii) формы Полномочий от Изготовителя и договоры с ключевыми Субподрядчиками;
(iv)
Список предлагаемых Субподрядчиков; (v) форма (формы) Залогового
обеспечения конкурсного предложения (если предусмотрено) и другие формы,
приведенные в главах с 1 по 4 настоящего Раздела VII Документации для торгов.

Форма Конкурсного предложения: Помимо того, что в форме Конкурсного
предложения официально подтверждаются цена предложения, разбивка на
валюты, срок (сроки) завершения работ и прочие важные детали Контракта,
Участник торгов также использует эту форму для того (если для данного
Контракта предусмотрен Третейский судья), чтобы подтвердить свое согласие с
кандидатурой Третейского судьи, предложенной Покупателем, или предложить
альтернативную кандидатуру. Если конкурсное предложение подается от имени
Раздел VII. Образцы форм
603
Совместного предприятия, форма Конкурсного предложения должна быть
подписана ответственным партнером, и к ней следует приложить
подтверждения полномочий и доверенности, предусмотренные в Статье ИУТ
6.2. С учетом широко распространенных опасений по поводу незаконного
использования лицензионного программного обеспечения каждый Участник
торгов должен подтвердить в форме Конкурсного предложения, что
предлагаемые Программные продукты либо были разработаны самим
Участником торгов и являются его собственностью, либо (в противоположном
случае) обеспечены действующими лицензиями, выданными собственником
таких Программных продуктов.

Таблицы цен: Цены, указанные в Таблицах цен, должны обеспечивать полную и
справедливую компенсацию расходов на поставку и установку Системы,
описанной в разделе «Технические требования», и ее доведение до стадии
Приемки в эксплуатацию в соответствии с Графиком реализации и условиями
предлагаемого Контракта, изложенными в Документации для торгов. Цены
должны быть указаны для каждой позиции, приведенной в Таблицах цен, а
расходы должны быть тщательно подытожены сначала на уровне Подсистемы,
а затем для Системы в целом. Если в Таблицах цен дается только общая
разбивка на узлы и компоненты или не охвачены некоторые детали, имеющие
уникальное значение для конкретного технического решения, предлагаемого
Участником торгов, то Участник торгов может расширить содержание Таблиц с
тем, чтобы охватить такие детали или компоненты. Если для полного
понимания конкурсного предложения необходимы вспомогательные таблицы
цен и расходов, их следует включить в состав конкурсного предложения.
Необходимо избегать арифметических ошибок. В случае обнаружения таких
ошибок Покупатель исправит их в соответствии со Статьей ИУТ 26.2 (Статьей
ИУТ 38.2 для двустадийной ТДТ), не проводя никаких консультаций с
соответствующим Участником торгов. При наличии серьезных опущений или
несоответствий, или в отсутствие деталей, являющихся обоснованием какихлибо цен, конкурсное предложение может быть отклонено как не
соответствующее предъявленным коммерческим требованиям. Есть и другая
причина, по которой цены должны быть представлены в соответствии с
разбивкой, предусмотренной в Таблицах цен. Если в конкурсном предложении
цены разделены не так, как это предусмотрено, и в результате Покупатель не
может применить льготу для отечественных товаров, если она предусмотрена в
данном конкурсе и описана в Статье ИУТ 29 (Статье ИУТ 41 для двустадийной
ТДТ), данный Участник торгов потеряет преимущество, которое дает эта
льгота. После вскрытия конкурсных предложений ни одну из этих проблем
устранить нельзя. На этом этапе Участникам торгов запрещается менять цены
конкурсных предложений в целях исправления ошибок или устранения
опущений.

Полномочия от Изготовителя и письменные соглашения с ключевыми
Субподрядчиками: В соответствии со Статьями ИУТ 6.1 (b) и (с) для всех
позиций, указанных в Информационной карте конкурсного предложения,
Участник торгов может быть обязан представить в составе своего предложения
Раздел VII. Образцы форм
604
Полномочия от Изготовителя по форме, приведенной в Документации для
торгов и соглашения с Субподрядчиками, предложенных для исполнения
ключевых услуг. Для таких соглашений особенного формата (или типовой
формы) не предусмотрено.

Список предлагаемых Субподрядчиков: Согласно Статье ИУТ 6.3, Участник
торгов должен представить в составе своего предложения Список предлагаемых
Субподрядчиков для наиболее важных позиций Технологий, Товаров и/или
Услуг. В этом списке должны быть также указаны наименования и места
регистрации Субподрядчиков, предлагаемых для каждой позиции, а также
краткие сведения об их квалификации.

Перечень Программных продуктов и Материалов: В соответствии со Статьей
ИУТ 13.1 (e) (vi) (Статьей ИУТ 13.1 (c) (vi) и 25.1 (e) (vi) для двустадийной
ТДТ) Участники торгов должны представить в составе своих конкурсных
предложений перечень всех предлагаемых Программных продуктов,
отнесенных к одной из следующих категорий: (A) Системные, Универсальные
или Прикладные программные продукты; или (B) Стандартные или
Кастомизированные программные продукты. Кроме того, Участники торгов
должны представить перечень всех Кастомизированных материалов. Если это
предусмотрено в Информационной карте конкурсного предложения,
Покупатель может оставить за собой право перераспределить отдельные
основные Программные продукты между категориями.

Формы квалификационной информации: В соответствии со Статьей ИУТ 6
Покупатель должен принять решение о том, обладает ли данный Участник
торгов необходимой квалификацией для выполнения Контракта. Для этого ему
необходимы критерии финансовой и технической оценки, а также критерии
оценки опыта работы, перечисленные в ИККП для Статьи ИУТ 6. Участник
торгов должен предоставить Покупателю информацию, необходимую для
проведения такой оценки, в рамках форм, которые приведены в настоящей
главе. В этих формах даются подробные дополнительные инструкции, которые
обязан соблюдать Участник торгов.

Залоговое обеспечение конкурсного предложения: Если, согласно ИККП для
Статьи 17 ИУТ (Статьи 29 для двустадийной ТДТ) предложения должны быть
обеспечены залогом, Участник торгов должен сделать это в соответствии с
условиями, которые указаны в соответствующей Статье ИУТ/ИККП, либо по
форме (формам), которые приведены в составе настоящих образцов форм, либо
в иной форме, приемлемой для Покупателя. Если Участник торгов хочет
использовать альтернативную форму Залогового обеспечения конкурсного
предложения, он должен проследить за тем, чтобы пересмотренный формат, по
существу, обеспечивал такую же защиту, как и стандартный формат; в
противном случае его конкурсное предложение может быть отклонено как не
отвечающее предъявленным коммерческим требованиям.
Участники торгов не обязаны представлять вместе со своими конкурсными
предложениями Залоговое обеспечение выполнения Контракта и Обеспечение
Раздел VII. Образцы форм
605
авансового платежа. Эти виды обеспечения должны быть предоставлены только тем
Участником торгов, который выбран Покупателем для присуждения Контракта.
Перечисленные далее формы должны быть заполнены и представлены
победителем торгов после получения уведомления о присуждении Контракта: (i)
Контрактное соглашение со всеми Приложениями; (ii) Залоговое обеспечение
выполнения Контракта; (iii) Обеспечение авансового платежа.

Контрактное соглашение: Помимо того, что Контрактное соглашение уточняет
стороны и Цену контракта, в нем определяются: (i) Представитель Поставщика;
(ii) если это применимо, согласованный сторонами Третейский судья и его/ее
вознаграждение; и (iii) Список согласованных Субподрядчиков. Кроме того, к
Соглашению прилагаются поправки к Таблицам цен, представленным в
предложении победителя торгов. К их числу относятся поправки и изменения
предложенных Поставщиком цен в целях исправления ошибок и корректировки
Цены Контракта с учетом (если это применимо) любого продления срока
действия конкурсных предложений по истечении первоначального срока
действия конкурсных предложений плюс 56 дней и т.д.

Залоговое обеспечение выполнения Контракта: Согласно Статье 13.3 ОУК,
победитель торгов должен предоставить Залоговое обеспечение выполнения
Контракта по форме, приведенной в настоящем разделе Документации для
торгов, и в размере, который определен в соответствии с положениями СУК.

Обеспечение авансового платежа: Согласно Статье 13.2 ОУК, победитель
торгов должен предоставить банковскую гарантию на полную сумму
авансового платежа по форме, если выплата Аванса предусмотрена в СУК для
Статьи 12.1 ОУК приведенной в настоящем разделе Документации для торгов,
или иной форме, приемлемой для Покупателя. Если Участник торгов хочет
предложить другую форму Обеспечения авансового платежа, он должен
незамедлительно направить один экземпляр такой формы Покупателю для
рассмотрения и подтверждения ее приемлемости до истечения срока подачи
конкурсных предложений.
В процессе выполнения Контракта Покупатель и Поставщик используют
следующие дополнительные формы для официального закрепления или
подтверждения важных этапов Контракта: (i) Сертификаты установки и приемки в
эксплуатацию; и (ii) различные формы, касающиеся Изменений. Эти формы и порядок
их использования в ходе выполнения Контракта представлены в Документации для
торгов для сведения Участников торгов.
Раздел VII. Образцы форм
606
Перечень Образцов форм
1. Форма Конкурсного предложения (одностадийные торги)..................................277
2. Формы Таблиц цен .......................................................................................................282
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Преамбула ..............................................................................................................283
Итоговая сводная таблица расходов ...................................................................285
Сводная таблица расходов на поставку и установку ........................................286
Сводная таблица текущих расходов ...................................................................290
Промежуточная таблица расходов на поставку и установку ...........................292
Промежуточная таблица текущих расходов ......................................................295
Коды стран происхождения товаров ...................................................................297
3. Прочие формы и перечни в составе Конкурсного предложения ........................298
3.1 Полномочия от Изготовителя ..............................................................................299
3.2 Список предлагаемых Субподрядчиков .............................................................300
3.3 Перечень Программных продуктов ....................................................................301
3.4 Перечень Кастомизированных материалов ........................................................302
3.5.1 Сведения общего характера .................................................................................303
3.5.2 Общие сведения об опыте работы с Информационными системами ..............304
3.5.2a Краткая характеристика Консорциума .........................................................305
3.5.3 Конкретные сведения об опыте работы с Информационными системами .....306
3.5.3a Подробная информация о контрактах, аналогичных по своему характеру и
сложности ..............................................................................................................307
3.5.4 Сводная таблица: текущие контрактные обязательства / работы,
выполняемые в настоящее время ........................................................................308
3.5.5 Финансовые возможности ...................................................................................309
3.5.6 Кадровый потенциал ............................................................................................311
3.5.6a Краткие сведения о кандидатах ......................................................................312
3.5.7 Технические возможности ...................................................................................313
3.5.8 Сведения об участии в судебных процессах ......................................................314
4. Форма Залогового обеспечения конкурсного предложения: Банковская
гарантия. ..............................................................................................................................315
4A. Форма Залогового обеспечения конкурсного предложения:Поручительство 319
5. Форма Контрактного соглашения .............................................................................321
Приложение 1. Представитель Поставщика...............................................................325
Приложение 2. Третейский судья................................................................................326
Приложение 3. Список согласованных Субподрядчиков .........................................327
Приложение 4. Категории Программных продуктов ................................................328
Приложение 5. Кастомизированные материалы ........................................................329
Приложение 6. Пересмотренные Таблицы цен..........................................................330
Приложение 7. Протокол переговоров по вопросам доработки Контракта и
согласованные поправки к Контракту ................................................................331
Раздел VII. Образцы форм
607
6. Формы Залогового обеспечения выполнения Контракта и Авансового платежа 332
6.1
6.2
Залоговое обеспечение выполнения Контракта: Банковская гарантия ...........333
Банковская гарантия Авансового платежа .........................................................335
7. Сертификаты установки и приемки в эксплуатацию ............................................337
7.1
7.2
Форма Сертификата установки ...........................................................................338
Форма Сертификата приемки в эксплуатацию ..................................................339
8. Порядок и формы внесения изменений....................................................................340
8.1
8.2
8.3
8.4
8.5
8.6
Форма Запроса о подготовке предложения об Изменении ...............................341
Форма Предварительной сметы Изменения .......................................................343
Форма Утверждения сметных расчетов .............................................................344
Форма Предложения об Изменении....................................................................345
Форма Распоряжения об Изменении ..................................................................347
Форма Заявки на подготовку предложения об Изменении ..............................349
Раздел VII. Образцы форм
608
1. ФОРМА КОНКУРСНОГО ПРЕДЛОЖЕНИЯ (ОДНОСТАДИЙНЫЕ
ТОРГИ)
Дата:[Участнику торгов указать дату конкурсного предложения]
Номер займа/кредита:[Покупателю указать номер]
ПУТ:[Покупателю указать название и номер ПУТ]
Контракт:[Покупателю указать название Контракта]
Куда: [Покупателю указать наименование и адрес Покупателя]
Уважаемый г-н/г-жа __________!
Изучив Документацию для торгов, включая Приложения №№ [указать
номера], получение которых настоящим подтверждается, мы, нижеподписавшиеся,
предлагаем поставить, установить, довести до стадии Приемки в эксплуатацию и
поддерживать Информационную систему в рамках вышеуказанного Контракта в
полном соответствии с вышеупомянутой Документацией для торгов, на сумму:
плюс
[указать сумму в местной
валюте прописью]
([указать сумму в местной
валюте цифрами, взяв для этого
Общий итог, приведенный в
Итоговой сводной таблице
расходов])
[указать сумму в
иностранной валюте A
прописью]
([указать сумму в иностранной
валюте A цифрами, взяв для
этого соответствующий Общий
итог, приведенный в Итоговой
сводной таблице расходов])
[в случае необходимости, добавить следующее]
плюс
[указать сумму в
иностранной валюте B
прописью]
([указать сумму в иностранной
валюте B цифрами, взяв для
этого соответствующий Общий
итог, приведенный в Итоговой
сводной таблице расходов])
плюс
[указать сумму в
иностранной валюте C
прописью]
([указать сумму в иностранной
валюте C цифрами, взяв для
этого соответствующий Общий
итог, приведенный в Итоговой
сводной таблице расходов])
Раздел VII. Образцы форм
609
или любую иную сумму, которая может быть установлена в соответствии с условиями
Контракта. Указанные выше суммы соответствуют Таблицам цен, которые
прилагаются к настоящей форме Конкурсного предложения и являются его составной
частью.
Если наше предложение будет принято, мы обязуемся приступить к работе над
Информационной системой и обеспечить ее Установку и Приемку в эксплуатацию в
сроки, указанные в Документации для торгов.
Если наше предложение будет принято, и, если того требует настоящая
Документация для Торгов, мы обязуемся предоставить обеспечение авансового
платежа и залоговое обеспечение выполнения Контракта по форме, на сумму и в
сроки, указанные в Документации для торгов.
[В случае необходимости, включить или убрать следующий абзац]
“Мы согласны с назначением в качестве Третейского судьи [Покупателю
указать Ф.И.О. Третейского судьи, предложенного в Информационной карте
конкурсного предложения].”
[и убрать следующий абзац, или, в зависимости от обстоятельств,
убрать предыдущий и включить следующий абзац, или, если в
Информационной карте конкурсного предложения нет никаких
указаний относительно Третейского судьи, убрать и предыдущий, и
следующий абзацы]
“Мы не согласны с назначением в качестве Третейского судьи [Покупателю
указать Ф.И.О. Третейского судьи, предложенного в Информационной карте
конкурсного предложения] и вместо него предлагаем назначить Третейским судьей
[указать Ф.И.О.], резюме и почасовая оплата услуг которого прилагаются к
настоящей форме Конкурсного предложения.”
Настоящим удостоверяем, что Программные продукты, которые составляют
предмет настоящего конкурсного предложения и подлежат поставке в рамках
Контракта, (i) либо являются нашей собственностью, либо (ii) если не являются нашей
собственностью, обеспечены действующей лицензией, выданной собственником таких
Программных продуктов.
Мы согласны выполнять условия настоящего конкурсного предложения, в
состав которого, в соответствии со Статьями ИУТ 13 и 16 , входят данное письмо
(форма Конкурсного предложения) и перечисленные далее приложения, в течение
[Покупателю указать
количество из Информационной карты конкурсного
предложения]дней после наступления даты, установленной для подачи конкурсных
предложений, как указано в Документации для торгов, и до истечения этого срока
настоящее конкурсное предложение будет иметь для нас обязательную силу и может
быть принято вами в любое время.
Комиссионные или денежные вознаграждения (если таковые имеются), которые
мы выплатили или должны выплатить агентам в связи с настоящим Конкурсным
предложением и выполнением Контракта, если он будет нам присужден, перечислены
ниже:
Раздел VII. Образцы форм
610
Наименование и
адрес агента
Сумма и
валюта
Предназначение
комиссионных
или денежного
вознаграждения
и т.д. [в случае отсутствия каких-либо комиссионных или
денежных вознаграждений, написать: “нет”]
До того, как будет составлен и официально заключен между нами
окончательный Контракт, настоящее конкурсное предложение вместе с вашим
письменным согласием на это предложение и вашим уведомлением о присуждении
Контракта является юридически обязательным договором между нами. Нам известно,
что вы не обязаны принимать предложение, имеющее наименьшую оценочную
стоимость, или вообще какое-либо из полученных вами предложений.
Датировано сегодняшним [указать порядковый номер] числом [указать
месяц],[указать год].
Подпись:
Дата:
[указать должность]
имеющий надлежащие полномочия на подписание настоящего конкурсного
предложения от имени и по поручению [указать наименование Участника торгов]
ПРИЛАГАЕМЫЕ ДОКУМЕНТЫ:
Таблицы цен
Залоговое обеспечение конкурсного предложения
Полномочия на подписание документов [плюс – для Совместных предприятий
– перечень всех прочих доверенностей, предусмотренных в Статье ИУТ 6.2]
Приложение 1
Право Участника на участие в торгах
Приложение 2
Квалификация Участника торгов (включая Полномочия от
Изготовителя и соглашения с Субподрядчиками, если
требуется)
Раздел VII. Образцы форм
Приложение 3
Приложение 4
Приложение 5
Приложение 6
611
Приемлемость Товаров и Услуг
Соответствие Информационной системы Документации
для торгов
Предлагаемые Субподрядчики
Интеллектуальная собственность (Перечни Программных
продуктов и Материалов)
[в случае необходимости, указать другие Приложения или прилагаемые
документы]
Раздел VII. Образцы форм
612
Содержание и перечень документов Конкурсного предложения
Примечание: Покупатели должны расширить и скорректировать (в зависимости от
обстоятельств) приведенную ниже таблицу, чтобы она отражала необходимые
компоненты конкурсного предложения Участника торгов. Как указано в следующем
примечании для Участников торгов, и Покупатель, и Участники торгов заинтересованы
в том, чтобы эта таблица была представлена и содержала точную информацию.
Примечание: Участники торгов должны расширить и (в случае необходимости)
скорректировать и заполнить приведенную ниже таблицу. Эта таблица нужна для
того, чтобы у Участников торгов был сводный перечень документов, которые
необходимо включить в состав конкурсного предложения, как указано в Статьях ИУТ
13.1 и 16, чтобы оно рассматривалось как кандидат для присуждения Контракта.
Кроме того, для облегчения и ускорения оценки предложений Покупателем в этой
таблице даются ссылки на номера страниц.
Документ
Форма Конкурсного предложения ..............................
Таблицы цен ..................................................................
Залоговое обеспечение конкурсного предложения ...
Полномочия на подписание документов (для
Совместных предприятий следует дополнительно
приложить доверенности, перечисленные в Статье
ИУТ 6.2) .........................................................................
Приложение 1 ................................................................
Приложение 2 ................................................................
Полномочия от Изготовителя
Соглашения с Субподрядчиками
Приложение 3 ................................................................
Приложение 4 ................................................................
Приложение 5 ................................................................
Приложение 6 ................................................................
.........................................................................................
Имеется:
да/нет
№
страницы
Раздел VII. Образцы форм
613
2. ФОРМЫ ТАБЛИЦ ЦЕН
Примечание: При закупках информационных систем Цена контракта (и график
платежей) должна быть как можно более тесно увязана не только с физической
доставкой технологий, но и с достижением рабочих показателей.
Раздел VII. Образцы форм
614
2.1
Преамбула
Примечание:
В Преамбуле к Таблицам цен Покупатели должны особо
подчеркнуть все специальные требования к Системе и Контракту. Ниже
приведен пример одной из таких преамбул.
Общие положения
1.
В состав Таблиц цен входят следующие отдельные таблицы:
2.2
Итоговая сводная таблица расходов
2.3
Сводная таблица расходов на поставку и установку
2.4
Сводная таблица текущих расходов
2.5
Промежуточная таблица расходов на поставку и установку
2.6
Промежуточная таблица текущих расходов
2.7
Коды стран происхождения товаров
[указать любые другие необходимые таблицы]
2.
В целом, эти таблицы не содержат полного описания информационных
технологий, которые должны быть поставлены, установлены и приняты в
эксплуатацию, или Услуг, которые должны быть предоставлены в рамках каждой
позиции. При этом предполагается, что до того, как проставить ставки и цены,
Участники торгов ознакомились с Техническими требованиями и другими
разделами настоящей Документации для торгов, и им известен весь объем
требований, касающихся каждой позиции. Считается, что указанные ставки и
цены учитывают весь объем этих Технических требований, а также накладные
расходы и прибыль.
3.
Если у Участников торгов нет ясности или уверенности относительно того, что
входит в состав той или иной позиции, они должны запросить разъяснения еще
до подачи предложения, как указано в Документации для торгов в разделе
«Инструкции участникам торгов».
Цены
4.
Цены проставляются несмываемые чернилами, а любые правки, связанные с
исправлением ошибок и т.п., должны быть парафированы Участником торгов.
Как указано в Информационной карте конкурсного предложения, цены должны
оставаться твердыми и неизменными в течение всего срока действия Контракта.
5.
Цены конкурсных предложений приводятся в той манере и в тех валютах, как
указано в ИУТ в Статьях 14 и 15 (Статьях 27 и 28 ИУТ для двустадийной ТДТ).
Цены должны соответствовать позициям того состава и качества, которые
определены в Технических требованиях или в других разделах настоящей
Документации для торгов.
Раздел VII. Образцы форм
615
6.
Участник торгов должен проводить расчеты очень аккуратно, поскольку по
истечении срока подачи конкурсных предложений исправление ошибок не
допускается. Одна ошибка в указанной цене единицы продукции может изменить
общую цену конкурсного предложения Участника торгов и таким образом
сделать предложение неконкурентоспособным или принести Участнику торгов
убытки. Покупатель исправит любые счетные ошибки в соответствии с
положениями Статьи ИУТ 26.2 (Статьи ИУТ 38.2 для двустадийной ТДТ).
7.
Платежи Поставщику осуществляются в валюте или валютах, указанных для
соответствующей позиции. Как отмечено в Статье ИУТ 15.1 (Статье ИУТ 28.1
для двустадийной ТДТ), можно использовать не более трех иностранных валют.
Цена одной и той же позиции должна быть одинаковой независимо от
установочной площадки.
Раздел VII. Образцы форм
616
2.2
Итоговая сводная таблица расходов
[указать цену
в местной
валюте]
1.
2.
Расходы на поставку и установку (из
Сводной таблицы расходов на
поставку и установку)
Общий итог (перенести в форму
Конкурсного предложения
Наименование Участника торгов:
Подпись полномочного представителя
Участника торгов:
[указать цену в
иностранной
валюте A]
[указать цену в
иностранной
валюте B]
[указать цену в
иностранной
валюте C]
Раздел VII. Образцы форм
617
2.3
Сводная таблица расходов на поставку и установку
Номер Системы или Подсистемы: [если закупки разбиты на несколько лотов, указать номер Подсистемы; в противном
случае написать “закупка Системы в целом”][перечислить позиции в приведенной далее таблице, изменяя, сокращая или
дополняя имеющиеся образцы отдельных статей и строк так, как это необходимо для поставки и установки Системы и ее
доведения до стадии Приемки в эксплуатацию.]
Расходы ДОЛЖНЫ отражать цены и ставки, указанные в соответствии со Статьями ИУТ 14 и 15.
Цены поставки и установки
Позиции,
относящие
ся к
местным
поставкам
№
позиц
ии
Подсистема / позиция
№
Промежут
очной
таблицы
расходов
на
поставку и
установку
ПРОМЕЖУТОЧНЫЕ ИТОГИ
[указать
цену в
местной
валюте]
Позиции, поставляемые из-за рубежа
[указать
цену в
местной
валюте]
[указать
цену в
иностранн
ой валюте
A]
[указать
цену в
иностранн
ой валюте
B]
[указать
цену в
иностранн
ой валюте
C]
Раздел VII. Образцы форм
618
Цены поставки и установки
Позиции,
относящие
ся к
местным
поставкам
№
позиц
ии
Подсистема / позиция
№
Промежут
очной
таблицы
расходов
на
поставку и
установку
[указать
цену в
местной
валюте]
Позиции, поставляемые из-за рубежа
[указать
цену в
местной
валюте]
[указать
цену в
иностранн
ой валюте
A]
[указать
цену в
иностранн
ой валюте
B]
[указать
цену в
иностранн
ой валюте
C]
ОБЩИЙ ИТОГ (в Итоговую сводную таблицу)
Примечание: - - означает «не применимо». “ означает «то же, что и предыдущей строке». Конкретные компоненты, входящие в
состав каждой Подсистемы, или отдельные позиции этой сводной таблицы описаны в соответствующей Промежуточной
таблице расходов на поставку и установку.
Наименование Участника торгов:
Подпись полномочного представителя
Участника торгов:
Раздел VII. Образцы форм
619
2.4
2.5
Сводная таблица текущих расходов – не применимо
Промежуточная таблица расходов на поставку и установку [указать идентификационный номер]
Номер Системы или Подсистемы: закупка Системы в целом Номер позиции:
[перечислить в приведенной далее таблице составные части вышеуказанной позиции и их количество, изменяя
имеющиеся образцы составных частей и строк так, как это необходимо для поставки и установки Системы и ее
доведения до стадии Приемки в эксплуатацию.Повторить эту таблицу столько раз, сколько необходимо для охвата
каждой и всех позиций Итоговой сводной таблицы расходов на поставку и установку, которые требуют расшифровки.]
Расходы ДОЛЖНЫ отражать цены и ставки, указанные в соответствии со Статьями ИУТ 14 и 15 . Цена единицы одной и той
же продукции, приведенная в таблице несколько раз, не должна меняться ни по сумме, ни по валюте.
Цена единицы продукции / ставка
Местная
поставка
№
Описание
компон компонента
ента
Код
Кол-во
страны
происхо
ждения
Поставка из-за рубежа
Общая цена
Местная
поставка
Поставка из-за рубежа
[указать [указать [указать
[указать [указать
[указать
[указать [указать
[указать [указать
иностран иностра иностра
иностран иностранн иностраместную местную
местную местную
ную
нную
нную
ную
ую валюту
ную
валюту] валюту]
валюту] валюту]
валюту валюту валюту
валюту
B]
валюту C]
A]
B]
C]
A]
Промежуточные итоги (для [указать каждой статьи] Сводной таблицы расходов на поставку и
установку
Примечание: - - означает «не применимо».
Раздел VII. Образцы форм
620
Наименование Участника торгов:
Подпись полномочного представителя
Участника торгов:
Раздел VII. Образцы форм
621
2.6
Промежуточная таблица текущих расходов–не применимо
Раздел VII. Образцы форм
622
2.7
Страна происхождения
Код страны
Коды стран происхождения товаров
Страна происхождения
Код страны
Страна
происхождения
Код страны
Раздел VII. Образцы форм
623
3. ПРОЧИЕ ФОРМЫ И ПЕРЕЧНИ В СОСТАВЕ КОНКУРСНОГО
ПРЕДЛОЖЕНИЯ
Раздел VII. Образцы форм
3.1
624
Форма Полномочий от Изготовителя
Наименование и номер Приглашения к участию в торгах
[если применимо:] Лот, часть лота или Подсистема №№
Куда: ________________________________
В ВИДУ ТОГО, ЧТО __________________________________________________,
являющийся официальным производителем ______________________________
____________________________________________________, производственные
мощности которого находятся в _________________________________________
__________________________________________________________, настоящим
уполномочивает ______________________________________________________,
расположенного по адресу _____________________________________________
________________________________________________________ (в дальнейшем
“Участник торгов”), представить конкурсное предложение и в дальнейшем
провести с вами переговоры и заключить Контракт на перепродажу
произведенных нами и перечисленных далее Продуктов: ____________________
_____________________________________________________________________
_____________________________________________________________________
Мы настоящим удостоверяем, что, если в результате торгов между Вами и
Участником будет заключен контракт, на вышеуказанные Продукты будет
распространяться наша полная стандартная гарантия.
Ф.И.О.:
Должность:
Подпись:
Имеющий надлежащие полномочия на подписание настоящего документа от
имени и по поручению: ________________________
__________ число _________________ месяца ______ года.
Примечание: Настоящее письмо должно быть написано на официальном
бланке Изготовителя, подписано компетентным лицом, уполномоченным на то,
чтобы брать обязательства от имени Изготовителя.
Раздел VII. Образцы форм
3.2
Статья
625
Списокпредлагаемых Субподрядчиков
Предлагаемый
Субподрядчик
Место регистрации и
квалификация
Раздел VII. Образцы форм
3.3
626
Перечень Программных продуктов
(для каждого продукта выбрать одну
из колонок)
(для каждого продукта
выбрать одну из
колонок)
Системный Универсал Прикладно Стандартн Кастомизи
Программный продукт программн
ьный
й
ый
рованный
ый
программн программн программн программн
продукт
ый
ый
ый
ый
продукт
продукт
продукт
продукт
Раздел VII. Образцы форм
3.4
627
Перечень Кастомизированных материалов
Кастомизированные материалы
Раздел VII. Образцы форм
628
3.5.1 Сведения общего характера
Эту форму должны заполнить все самостоятельные фирмы и каждый из
партнеров Совместного предприятия, которые участвуют в торгах. Все
собственники или Участники торгов, которые являются партнерствами или
фирмами, находящимися в единоличной собственности, должны указать свою
национальную принадлежность.
Если Участник торгов предполагает использовать для выполнения
узкоспециализированных частей Информационной системы обозначенных здесь
Субподрядчиков, для таких Субподрядчиков необходимо представить
перечисленные далее сведения в дополнение к информации, приведенной в
формах 3.5.2, 3.5.3, 3.5.3a, 3.5.4 и 3.5.5. Совместные предприятия должны также
заполнить форму 3.5.2a.
1.
2.
3.
4.
5.
Название фирмы
Адрес головного офиса
Телефон
Факс
Место учреждения / регистрации
Национальная принадлежность собственников¹
Ф.И.О.
1.
2.
3.
4.
Контактное лицо
Телекс
Год учреждения / регистрации
Национальная принадлежность
5.
¹/
Заполняется всеми собственниками партнерств или фирм, находящихся в единоличной
собственности
Раздел VII. Образцы форм
629
3.5.2 Общие сведения об опыте работы с Информационными
системами
Наименование Участника торгов или партнера Совместного предприятия
Все самостоятельные фирмы и все партнеры Совместных предприятий должны
дать в этой форме общую информацию о выполнении контрактов, связанных с
Информационными системами. Здесь следует дать сведения о годовом обороте
Участника торгов (или каждого члена Совместного предприятия), выраженного
в объеме счетов, которые ежегодно выставлялись клиентам за выполняемые или
завершенные работы. Суммы счетов должны быть конвертированы в доллары
США по курсу обмена на конец отчетного периода. Год должен быть равен
календарному году; при этом следует учитывать часть года, истекшую на
момент подачи конкурсного предложения. Для Субподрядчиков эта форма
заполняется только в том случае, если в Информационной карте конкурсного
предложения для Статьи ИУТ 6.1 (a) однозначно указано, что опыт и ресурсы
(некоторых) Субподрядчиков учитываются при оценке квалификации
Участника торгов.
К форме следует приложить краткое описание каждого контракта с указанием
характера Информационной системы, продолжительности и суммы контракта,
схемы управления контрактом, покупателя и другой необходимой информации.
Для каждого партнера Совместного предприятия сведения даются на отдельных
листах, которые пронумеровываются.
Участники торгов не должны прилагать к своему предложению никаких
аттестатов, сертификатов или рекламных материалов; в процессе оценки
квалификации они не учитываются.
Сведения о годовом обороте (только для соответствующей деятельности)
Год¹
Оборот
Эквивалентная сумма в
долларах США
1.
2.
3.
4.
5.
¹/
Начиная с незавершенного года вплоть момента подачи
конкурсного предложения
Раздел VII. Образцы форм
630
3.5.2aКраткая характеристика Совместного предприятия
Наименования всех партнеров по Совместному предприятию
1. Ответственный партнер
2. Партнер
3. Партнер
4. Партнер
5. Партнер
6. и т.д.
Общая величина ежегодного оборота, выраженная в объеме счетов,
выставленных клиентам за Информационные системы. Суммы должны быть
конвертированы в доллары США по курсу обмена на конец отчетного периода.
Сведения о годовом обороте (только для соответствующей деятельности;
эквивалентная сумма в долларах США)
Партнер
№ страницы Год 1
Год 2
Год 3
Год 4
в форме
3.5.2
1. Ответственный партнер
2. Партнер
3. Партнер
4. Партнер
5. Партнер
6. и т.д.
Итого
Год 5
Раздел VII. Образцы форм
631
3.5.3 Конкретные сведения об опыте работы с
Информационными системами
Наименование Участника торгов или партнера Совместного предприятия
На отдельных листах (по форме 3.5.3a) Участник торгов должен перечислить
контракты, аналогичные по своему характеру и сложности и требовавшие
применения той же информационной технологии и методики, что и контракт
или контракты, являющиеся предметом настоящей Документации для торгов,
которые были выполнены Участником торгов за период, указанный в ИККП для
Статьи ИУТ 6.1 (a). Каждый партнер Совместного предприятия должен
отдельно представить сведения о своих соответствующих контрактах.
Стоимость контрактов должна быть указана с учетом валют контрактных
платежей, переведенных в доллары США по курсу обмена на момент
завершения основных работ, или – для текущих контрактов – на момент
присуждения контракта.
Раздел VII. Образцы форм
632
3.5.3aПодробная информация о контрактах, аналогичных по
своему характеру и сложности
Наименование Участника торгов или партнера Совместного предприятия
1.
2.
3.
4.
5.
Для каждого контракта сведения даются на отдельном листе.
Номер контракта
Название контракта
Страна
Наименование Покупателя
Адрес Покупателя
Характер Информационных систем и особенности, имеющие значение для контракта,
заключение которого является целью настоящей Документации для торгов
Роль в рамках контракта (отметить один из следующих вариантов)
Главный поставщик  Управляющий подрядчик
 Партнер по Совместному предприятию

Субподрядчик
6.
Общая сумма контракта/сумма по договору субподряда/доля партнера (в указанных
валютах на момент завершения работ или по состоянию на день присуждения
контракта для текущих контрактов)
Валюта
Валюта
Валюта
7.
Эквивалентная сумма в долларах США
Общая сумма контракта: $_______; Сумма по договору субподряда: $_______;
Доля партнера: $_______;
День присуждения/завершения контракта
Работы по контракту были завершены на _____ месяцев раньше/позже первоначально
запланированного срока (в случае отставания от графика объяснить причины
отставания).
На момент завершения контракта его сумма была на _________ в долларовом
эквиваленте меньше/больше первоначально запланированной суммы (в случае
превышения первоначальной суммы контракта объяснить причины превышения).
Особые контрактные/технические требования.
Указать приблизительную долю субподряда (если таковой был) в общей контрактной
стоимости Информационной системы (и сумму в долларах США) и описать характер
Информационной системы.
8.
9.
10.
11.
12.
Раздел VII. Образцы форм
633
3.5.4 Сводная таблица: текущие контрактные обязательства / работы,
выполняемые в настоящее время
Наименование Участника торгов или партнера Совместному предприятию
Участники торгов и каждый партнер Совместного предприятия должны дать в
этой форме информацию о своих текущих обязательствах по всем
присужденным контрактам, по всем контрактам, в отношении которых было
получено письмо о намерении заключить контракт или согласие на заключение
контракта, и по всем контрактам, завершающимся в ближайшее время, но еще
не подтвержденным безоговорочным сертификатом о полном завершении
работ.
Название
контракта
1.
2.
3.
4.
5.
и т.д.
Покупатель,
Стоимость
Расчетный срок
контактный
незавершенной
завершения
адрес/тел./факс Информационной работ
системы (текущая
эквивалентная
сумма в долларах
США)
Среднемесячный
объем счетов,
выставленных в
течение
последних шести
месяцев
(доллары
США/мес.)
Раздел VII. Образцы форм
3.5.5
634
Финансовые возможности
Наименование Участника торгов или партнера Совместного предприятия
Участники торгов, включая каждого партнера Совместного предприятия,
должны дать в этой форме финансовую информацию, демонстрирующую, что
они отвечают требованиям, изложенным в ИККП для Статьи ИУТ 6.1 (a). Эта
форма заполняется каждым Участником торгов или партнером Совместного
предприятия. В случае необходимости следует приложить отдельные листы,
чтобы дать исчерпывающую информацию о банкире. Кроме того, форме
прилагаются балансовые отчеты, прошедшие аудиторскую проверку.
Самостоятельные подразделения материнских конгломератов представляют
финансовую информацию только о соответствующей деятельности своего
подразделения.
Банкир
Наименование банкира
Адрес банкира
Телефон
Ф.И.О. и должность контактного
лица
Факс
Телекс
Дать краткую информацию о фактических активах и пассивах за пять
предшествующих календарных лет в долларовом эквиваленте (по курсам
обмена на конец каждого года). С учетом известных обязательств дать краткую
информацию о прогнозируемых активах и пассивах на два следующих
календарных года в долларовом эквиваленте, за исключением тех случаев, когда
Участник торгов может доказать необходимость неразглашения такой
информации для публичных компаний, чьи акции котируются на фондовой
бирже.
Финансовая
Факт:
Прогноз:
информация
Пять предшествующих лет
Два следующих
(эквивалентная
года
сумма в
долларах США)
5
4
3
2
1
1
2
1. Суммарные
активы
2. Текущие
активы
3. Суммарные
пассивы
4. Текущие
пассивы
5. Прибыль до
вычета налогов
6. Прибыль
после вычета
налогов
Раздел VII. Образцы форм
635
Перечислить предполагаемые источники финансирования, такие, как ликвидные
активы, необремененная недвижимость, кредитные линии и прочие имеющиеся
финансовые средства за вычетом текущих обязательств, с помощью которых
можно будет выполнить требования к общему объему «конструктивного»
потока наличности в рамках рассматриваемого контракта или контрактов,
изложенные в ИККП для Статьи ИУТ 6.1 (a).
Источник финансирования
Эквивалентная сумма в
долларах США
1.
2.
3.
4.
Приложить прошедшие аудиторскую проверку финансовые отчеты (включая,
как минимум, отчет о прибылях и убытках, баланс и пояснительные
примечания) за период, указанный в ИККП для Статьи ИУТ 6.1 (a) (для каждого
самостоятельного Участника торгов или каждого партнера Совместного
предприятия).
Если законодательство стран Участников торгов не требует проведения аудита,
партнерства или фирмы, находящиеся в единоличной собственности, могут
представить
свои
балансовые
отчеты,
заверенные
официально
зарегистрированным бухгалтером, с приложением копий налоговых
деклараций.
Раздел VII. Образцы форм
3.5.6
636
Кадровый потенциал
Наименование Участника торгов
Для конкретных должностей, имеющих большое значение для управления
контрактом и его выполнения (и/или должностей, перечисленных в
Документации для торгов (если таковые имеются)), Участники торгов должны
дать Ф.И.О., как минимум, двух кандидатов, квалификация которых
соответствует требованиям, оговоренным для каждой такой должности.
Сведения об опыте каждого кандидата должны быть представлены на
отдельном листе по форме 3.5.6a.
Участники торгов могут предложить альтернативную схему управления
контрактом и его выполнения, требующую других ключевых сотрудников; при
этом они должны представить информацию об опыте таких сотрудников.
1.
2.
3.
4.
Название должности
Ф.И.О. главного кандидата
Ф.И.О. второго кандидата
Название должности
Ф.И.О. главного кандидата
Ф.И.О. второго кандидата
Название должности
Ф.И.О. главного кандидата
Ф.И.О. второго кандидата
Название должности
Ф.И.О. главного кандидата
Ф.И.О. второго кандидата
Раздел VII. Образцы форм
637
3.5.6aКраткие сведения о кандидатах
Наименование Участника торгов
Должность
Кандидат

Сведения о
кандидате
Ф.И.О. кандидата
Главный
Дата рождения

Второй
Профессиональная квалификация
Место
работы в
настоящее
время
Наименование Работодателя
Адрес Работодателя
Телефон
Факс
Название должности кандидата по
месту работы
Контактное лицо (руководитель /
сотрудник отдела кадров)
Телекс
Стаж работы на данном месте
Дать краткую информацию о профессиональном опыте за последние двадцать
лет в обратном хронологическом порядке. Указать конкретный технический и
административный опыт, имеющий значение для рассматриваемого проекта.
Дата
поступле
ния
Дата
Компания/проект/должность/соответствующий
увольнен административный опыт
ия
технический
и
Раздел VII. Образцы форм
3.5.7
638
Технические возможности
Наименование Участника торгов
Участник торгов должен представить необходимую и достаточную
информацию, которая убедительно продемонстрирует, что имеет технические
возможности для того, чтобы выполнить требования, предъявляемые к данной
Информационной системе. В этой форме Участник торгов должен дать краткую
информацию о важных проверках, собственных методиках и/или
специализированных технологиях, которые он предполагает использовать в
процессе выполнения Контракта или Контрактов.
Раздел VII. Образцы форм
3.5.8
639
Сведения об участии в судебных процессах
Наименование Участника торгов или партнера Совместного предприятия
Участники торгов, включая каждого партнера Совместного предприятия,
должны представить информацию о своем участии в любых судебных
процессах или арбитражных разбирательствах, связанных с контрактами,
которые они выполнили за последние пять лет или выполняют в настоящее
время. Сведения о каждом партнере Совместного предприятия даются на
отдельном листе.
Год
Решение В Наименование клиента, причина судебного Оспариваемая
ПОЛЬЗУ или разбирательства и предмет спора
сумма
(текущая
ПРОТИВ
стоимость
в
Участника
долларовом
торгов
эквиваленте)
Раздел VII. Образцы форм
640
4. ГАРАНТИЙНАЯ ДЕКЛАРАЦИЯ
Не применимо
Раздел VII. Образцы форм
641
4А обеспечение конкурсного предложения (Банковская
гарантия)
________________________________
[указать название Банка и адрес филиала или отделения, выдавшего
гарантию]
Бенефициар:
[указать наименование и адрес Покупателя]
Дата: [указать дату]
№ ГАРАНТИИ КОНКУРСНОГО ПРЕДЛОЖЕНИЯ: [указать номер
гарантии Конкурсного предложения]
Мы получили информацию о том, что [указать наименование Участника
торгов] (в дальнейшем "Участник торгов") представил вам свое предложение
от [указать дату конкурсного предложения] (в дальнейшем "Предложение") о
выполнении [указать название Контракта] на основании Приглашения к
участию в торгах № [указать номер ПУТ] (“ПУТ”).
Нам также известно, что в соответствии с вашими условиями предложения
должны сопровождаться гарантией.
По просьбе Участника торгов мы [указать название Банка] настоящим берем
на себя безотзывное обязательство выплатить вам любую сумму или суммы в
общей сложности не более [указать сумму в цифрах] ([указать сумму
прописью]) по вашему первому письменному требованию, к которому должно
прилагаться письменное заявление о том, что Участник торгов нарушил свое
обязательство (обязательства) в рамках Предложения, поскольку он:
(a)
отозвал свое Предложение до истечения срока действия
конкурсных предложений, указанного Участником торгов в
форме Конкурсного предложения; или
(b)
получив до истечения срока действия конкурсных предложений
уведомление о том, что его Предложение принято Покупателем, (i)
не заключил или отказался заключить Контракт по форме
Контракта (если это предусмотрено требованиями), или (ii) не
предоставил или отказался предоставить залоговое обеспечение
выполнения Контракта в соответствии с положениями ИУТ.
Настоящая гарантия действительна: (a) в том случае, если Участник торгов
станет победителем конкурса, до того момента, когда мы получим копии
контракта, подписанного Участником торгов, а вам, по указанию Участника
торгов, будет предоставлено залоговое обеспечение выполнения контракта; или
(b) в том случае, если Участник торгов не станет победителем конкурса, до
наступления более ранней из двух следующих дат: (i) день получения нами
копии вашего уведомления Участнику торгов с указанием имени победителя
конкурса, или (ii) день, наступающий через двадцать восемь дней после
окончания срока действия Предложения Участника торгов.
Раздел VII. Образцы форм
642
Следовательно, любое платежное требование в рамках настоящей гарантии
должно быть получено нашим офисом не позднее указанного срока.
Настоящая гарантия регулируется Едиными
востребования (Публикация МТП № 458).
правилами
гарантий
до
_____________________________
[подпись(подписи)]
[Примечание для Участников: Инструкции по сумме и валюте могут быть найдены в Статье
ПУТ и ИКПП «Обеспечение Конкурсного предложения. Совместные предприятия должны
также обеспечить выполнение требований к Совместным предприятиям, приведенным в той
же Статье]
Раздел VII. Образцы форм
643
4B. ОБЕСПЕЧЕНИЕ КОНКУРСНОГО
ПРЕДЛОЖЕНИЯ:(ПОРУЧИТЕЛЬСТВО)
НЕ ПРИМЕНИМО
5. КОНТРАКТНОЕ СОГЛАШЕНИЕ
НАСТОЯЩЕЕ КОНТРАКТНОЕ СОГЛАШЕНИЕ заключено
[указать порядковый номер] числа [указать месяц], [указать год].
МЕЖДУ
(1)
[указать
наименование Покупателя],[указать
тип
юридического лица, например, организация Министерства . . .]
Правительства [указать страну Покупателя], или корпорацией,
учрежденной в качестве юридического лица в соответствии с
законодательством [указать страну Покупателя], и имеющий
юридический адрес: [указать адрес Покупателя] (в дальнейшем
“Покупатель”), и
(2)
[указать
наименование
Поставщика],
корпорацией,
учрежденной в качестве юридического лица в соответствии с
законодательством [указать страну Поставщика], и имеющей
юридический адрес: [указать адрес Поставщика](в дальнейшем
“Поставщик”).
В ВИДУ ТОГО, ЧТО Покупатель хочет привлечь Поставщика для поставки,
установки, доведения до стадии Приемки в эксплуатацию и поддержки
Информационной системы [вставить: краткое описание Информационной
системы](“Система”), а Поставщик согласился выполнить эту работу на
условиях, изложенных далее в настоящем Контрактном соглашении,
НАСТОЯЩИМ СТОРОНЫ ДОГОВОРИЛИСЬ о нижеследующем:
Статья 1.
Контрактная
документация
1.1
Контрактная документация (со ссылкой на Статью 1.1 (a) (ii)
ОУК)
Перечисленные далее документы составляют Контракт
между Покупателем и Поставщиком, и каждый из них
подлежит прочтению и толкованию как неотъемлемая часть
Контракта:
(a)
Настоящее Контрактное соглашение и Приложения к
Контрактному соглашению
Раздел VII. Образцы форм
1.2
644
(b)
Специальные условия контракта
(c)
Общие условия контракта
(d)
Технические требования (включая График реализации)
(e)
Конкурсное
предложение
первоначальные Таблицы цен
(f)
[здесь добавить: любые другие документы]
Поставщика
и
Порядок старшинства (со ссылкой на Статью 2 ОУК)
В случае какой-либо неясности или противоречия между
перечисленными
выше
компонентами
Контрактной
документации
соблюдается
порядок
старшинства,
соответствующий тому порядку, в каком эти документы
перечислены
выше
в
Статье
1.1
(Контрактная
документация), при условии, что Приложение 7 имеет
преимущественную силу перед всеми положениями
Контрактного соглашения и остальными Приложениями к
Контрактному соглашению, а также перед всеми другими
компонентами
Контрактной
документации,
перечисленными выше в Статье 1.1.
1.3
Определения (со ссылкой на Статью 1 ОУК)
Используемые в настоящем Контрактном соглашении слова
и выражения, начинающиеся с прописных букв, имеют те
же значения, которые приписаны им в Общих условиях
контракта.
Статья 2.
2.1
Цена
контракта и
Условия
платежа
Цена контракта (со ссылкой на Статью 1.1(a)(viii) и Статью
11 ОУК)
Настоящим Покупатель соглашается выплатить Поставщику
Цену контракта за выполнение Поставщиком его
обязательств по Контракту. Цена контракта представляет
собой сумму: [указать сумму в иностранной валюте A
прописью],[указать
сумму цифрами], плюс [указать
сумму в иностранной валюте B прописью],[указать
сумму цифрами], плюс [указать сумму в иностранной
валюте C прописью], [указать
сумму цифрами],
[указать сумму в местной валюте прописью], [указать
сумму цифрами], как указано в Итоговой сводной таблице
расходов.
Подразумевается, что Цена контракта отражает условия,
которые
учитывались
при
определении
цен
в
детализированных Таблицах цен, включая условия
соответствующих ИНКОТЕРМов, а также налоги, пошлины
и сопутствующие сборы (если они определены и так, как
они определены).
Статья 3.
Дата
вступления в
3.1
Дата вступления в силу (со ссылкой на Статью 1.1 (e) (ix)
ОУК)
Срок, который дается на поставку и установку Системы и ее
Раздел VII. Образцы форм
645
доведение до стадии Приемки в эксплуатацию,
отсчитывается от того дня, когда были выполнены все
нижеперечисленные условия:
силу,
учитываемая
при
определении
срока
Приемки в
эксплуатацию
(a)
настоящее Контрактное соглашение подписан в
установленном порядке от имени и по поручению
Покупателя и Поставщика;
(b)
Поставщик предоставил Покупателю залоговое
обеспечение выполнения Контракта и обеспечение
авансового платежа в соответствии с положениями
Статей 13.2 и 13.3 ОУК;
(c)
Покупатель произвел авансовый платеж Поставщику в
соответствии с положениями Статьи 12 ОУК;
(d)
[здесь перечислить: любые другие условия, например,
открытие/подтверждение аккредитива].
Каждая из сторон делает все возможное для скорейшего
выполнения вышеизложенных условий, которые относятся к
сфере ее обязательств.
Статья 4.
3.2
Если условия, перечисленные в пункте 3.1 выше, не будут
выполнены в течение двух (2) месяцев после даты
заключения настоящего Контрактного соглашения по
причинам, не зависящим от Поставщика, стороны должны
обсудить и согласовать справедливую корректировку Цены
контракта и Даты приемки в эксплуатацию и/или других
соответствующих условий Контракта.
4.1
Перечисленные ниже Приложения являются неотъемлемой
частью настоящего Контрактного соглашения.
4.2
Ссылка в тексте Контракта на какое-либо Приложение
означает ссылку на Приложения, которые перечислены
ниже и прилагаются к настоящему Контрактному
соглашению, и Контракт подлежит прочтению и
толкованию в соответствии с ними.
Приложения
ПРИЛОЖЕНИЯ
Приложение 1
Представитель Поставщика
Приложение 2 Третейский судья [при отсутствии Третейского судьи
написать (“не применимо”)]
Приложение 3
Список согласованных Субподрядчиков
Приложение 4
Категории Программных продуктов
Приложение 5
Кастомизированные материалы
Приложение 6
Пересмотренные Таблицы цен (если таковые
имеются)
Приложение 7 Протокол переговоров по вопросам доработки Контракта
и согласованные поправки к Контракту
Раздел VII. Образцы форм
646
Раздел VII. Образцы форм
647
В УДОСТОВЕРЕНИЕ ЧЕГО настоящее Соглашение подписан в установленном
порядке полномочными представителями Покупателя и Поставщика в день и
год, указанные в начале этого документа.
От имени и по поручению Покупателя
Подпись:
Должность: [указать должность или иное приемлемое определение]
в присутствии
От имени и по поручению Поставщика
Подпись:
Должность: [указать должность или иное приемлемое определение]
в присутствии
КОНТРАКТНОЕ СОГЛАШЕНИЕ
от [указать цифру]числа [указать месяц], [указать год]
МЕЖДУ
[указать наименование Покупателя],“Покупатель”
и
[указать наименование Поставщика], “Поставщик”
Раздел VII. Образцы форм
648
Приложение 1. Представитель Поставщика
В соответствии с положениями Статьи 1.1 (b) (iv) ОУК Представителем
Поставщика является:
Ф.И.О.: [указать Ф.И.О., а ниже привести должность и адресили
написать “должен быть назначен в течение четырнадцати
(14) дней после Даты вступления в силу”]
Должность: [если возможно, указать должность]
В соответствии с положениями Статьи 4.3 ОУК адресами Поставщика для
получения извещений по Контракту являются:
Адрес Представителя Поставщика: [по возможности указать адреса для
личной доставки, почтовый, для каблограмм, телеграфный,
телекс, факсимильный, электронной почты и/или в системе
ЭОИ]
Раздел VII. Образцы форм
649
Приложение 2. Третейский судья
В соответствии с положениями Статьи 1.1 (b) (vi) ОУК в качестве Третейского
судьи согласована следующая кандидатура
Ф.И.О.[указать Ф.И.О.]
Должность:[указать должность]
Адрес: [указать почтовый адрес]
Телефон: [указать телефон]
В соответствии с положениями Статьи 6.1.3 ОУК согласованы следующий
размер оплаты и возмещаемые расходы:
Почасовая оплата:[указать почасовую оплату]
Возмещаемые расходы:[перечислить: возмещаемые расходы]
Согласно Статье 6.1.4 ОУК, если на момент подписания Контракта Покупатель
и Поставщик не смогли достичь договоренности, Третейский судья назначается
Назначающим органом, указанным в СУК.
Раздел VII. Образцы форм
650
Приложение 3. Список согласованных Субподрядчиков
Покупатель согласился с привлечением перечисленных далее Субподрядчиков,
которые были предложены Поставщиком для выполнения указанной позиции
или компонента Системы. Если для одной позиции перечислены несколько
Субподрядчиков, Поставщик имеет право выбрать любого из них, однако он
должен сообщить Покупателю о своем выборе до того момента, когда должны
начаться субподрядные работы, чтобы у Покупателя было достаточно времени
для рассмотрения принятого решения. В соответствии с положениями Статьи
20.1 ОУК Поставщик имеет право периодически предлагать кандидатуры
Субподрядчиков по дополнительным позициям. Что касается дополнительных
позиций, то ни с одним из таких Субподрядчиков договор субподряда не может
быть заключен до тех пор, пока кандидатуры этих Субподрядчиков не будут
одобрены Покупателем в письменном виде, а их имена не будут включены в
настоящий список согласованных Субподрядчиков с учетом положений Статьи
20.3 ОУК.
[ перечислить: позицию, место регистрации и кандидатуры согласованных
Субподрядчиков, которых Поставщик предложил в соответствующем
Приложении к своему конкурсному предложению, а Покупатель одобрил для
использования Поставщиком при выполнении Контракта.
В случае
необходимости приложить дополнительные листы.]
Позиция
Согласованные Субподрядчики
Место регистрации
Раздел VII. Образцы форм
651
Приложение 4. Категории Программных продуктов
В приведенной ниже таблице каждый конкретный Программный продукт,
поставляемый и инсталлируемый в рамках Контракта, отнесен к одной из трех
следующих категорий: (i) Системный программный продукт, (ii)
Универсальный Программный продукт, или (iii) Прикладной программный
продукт, а также к одной из двух следующих категорий: (i) Стандартный
программный продукт, или (ii) Кастомизированный программный продукт.
(для каждого продукта выбрать одну
из колонок)
(для каждого продукта
выбрать одну из
колонок)
Системный Универсал Приклад- Стандартн Кастомизи
Программный продукт программн
ьный
ной
ый
рованный
ый
программн программн программн программн
продукт
ый
ый
ый
ый
продукт
продукт
продукт
продукт
Раздел VII. Образцы форм
652
Приложение 5. Кастомизированные материалы
В приведенной ниже таблице перечислены Кастомизированные материалы,
которые Поставщик должен предоставить в рамках Контракта.
Кастомизированные материалы
Раздел VII. Образцы форм
653
Приложение 6. Пересмотренные Таблицы цен
Прилагаемые пересмотренные Таблицы цен (если таковые имеются) являются
частью настоящего Контрактного соглашения и при наличии расхождений
заменяют Таблицы цен, включенные в состав Конкурсного предложения
Поставщика. Эти пересмотренные Таблицы цен отражают все исправления или
поправки к цене предложения Поставщика в соответствии с положениями
Статей ИУТ 18.3, 26.2 и 33.1 (Статей ИУТ 30.3, 38.2 и 45.1 для двустадийной
ТДТ).
Раздел VII. Образцы форм
654
Приложение 7. Протокол переговоров по вопросам доработки
Контракта и согласованные поправки к Контракту
Прилагаемые поправки к Контракту (если таковые имеются) являются частью
настоящего Контрактного соглашения и при наличии расхождений заменяют
соответствующие положения ОУК, СУК, Технических требований или иных
компонентов настоящего Контракта, которые определены в Статье 1.1 (a) (ii)
ОУК.6. Формы обеспечения выполнения Контракта и Авансового платежа
Раздел VII. Образцы форм
655
6. ФОРМЫ ОБЕСПЕЧЕНИЯ ВЫПОЛНЕНИЯ КОНТРАКТА И
АВАНСОВОГО ПЛАТЕЖА
Раздел VII. Образцы форм
6.1
656
Форма Обеспечения выполнения Контракта (Банковская
гарантия)
________________________________
[указать: название банка и адрес филиала или отделения]
Бенефициар:[указать: Название и адрес Покупателя]
Дата:[указать: дату]
ГАРАНТИЯ ВЫПОЛНЕНИЯ КОНТРАКТА №:[вставить номер Гарантии
выполнения Контракта]
Мы получили информацию, что [указать: дату присуждения контракта]
Вами присужден Контракт № [указать: номер контракта] [указать: полное
наименование Поставщика] (здесь и далее именуемый «Поставщик») на
[указать: название и/или краткое описание контракта] (здесь и далее
именуемый «Контракт». Кроме того, как мы понимаем, по условиям Контракта
требуется предоставление гарантии выполнения контракта.
По запросу Поставщика, мы настоящим берем на себя безотзывное
обязательство выплатить Вам любую сумму (суммы) в пределах [указать:
сумму (суммы)1 цифрами и прописью] по получении нами Вашего первого
письменного требования, объявляющего о нарушении Контракта Поставщиком,
без придирок или возражений, без необходимости с Вашей стороны
предъявлять доказательства или приводить причины или основания Вашего
требования указанной здесь суммы.
В день подписания Вами и Поставщиком Сертификата приемки Системы в
эксплуатацию сумма настоящей гарантии будет уменьшена до суммы (сумм), не
превышающей [указать: сумму (суммы) цифрами и прописью]. Эта
остаточная гарантия будет иметь срок действия не менее [указать число и
выбрать месяцев/лет (Гарантийного периода, который должен быть
обеспечен остаточной гарантией)] с даты Сертификата приемки Системы в
эксплуатацию2, и любое требование по данной гарантии должно быть получено
нами в настоящем отделении не позднее этой даты.
Настоящая гарантия подчиняется Унифицированным правилам гарантий по
требованию, издание МТП № 458, кроме параграфа (ii) Статьи 20 (а), который
настоящим исключается.
____________________________
1
Банк должен вписать сумму (суммы), указанную в Статьях СУК для ОУК 13.3.1 и 13.3.4
соответственно, либо в валюте (валютах) Контракта, либо в свободно
конвертируемой валюте, приемлемой для Покупателя.
2
В данной типовой форме формулировка этого параграфа отражает обычные условия
СУК для Статьи ОУК 13.3. Однако, если СУК для Статей ОУК 13.3.1 и 13.3.4
отличаются от обычных условий, этот и, возможно, предыдущий параграфы должны
быть поправлены для боле точного соответствия положениям, данным в СУК.
Раздел VII. Образцы форм
[Подпись (подписи)]
657
Раздел VII. Образцы форм
6.2
658
Форма обеспечения Авансового платежа (Банковская
гарантия)
________________________________
[указать: название банка и адрес филиала или отделения]
Бенефициар:[указать: Название и адрес Покупателя]
Дата:[указать: дату]
ГАРАНТИЯ АВАНСОВОГО ПЛАТЕЖА №:[вставить номер Гарантии
авансового платежа]
Мы получили информацию, что [указать: дату присуждения контракта]
Вами присужден Контракт № [указать: номер контракта] [указать: полное
наименование Поставщика] (здесь и далее именуемый «Поставщик») на
[указать: название и/или краткое описание контракта] (здесь и далее
именуемый «Контракт». Кроме того, как мы понимаем, по условиям Контракта
Поставщику выплачивается авансовый платеж в размере [указать: сумму
(суммы) цифрами и прописью в каждой валюте авансового платежа] против
предоставления гарантии авансового платежа.
По запросу Поставщика, мы настоящим берем на себя безотзывное
обязательство выплатить Вам любую сумму (суммы) в пределах суммы
вышеуказанного авансового платежапо получении нами Вашего первого
письменного требования, объявляющего о нарушении Контракта Поставщиком,
так как Поставщик использовал авансовый платеж на цели, отличные от
надлежащего выполнения Контракта.
Любое требование или платеж по данной гарантии могут быть произведены
только при условии, что вышеуказанный авансовый платеж получен
Поставщиком на его счет [указать: номер и местонахождение счета].
При произведении каждого последующего после авансового платежа, который
Вы произведете Поставщику по настоящему Контракту, максимальная сумма
настоящей гарантии будет уменьшена на одну девятую часть суммы такого
платежа1.В тот момент, когда гарантийная сумма обнуляется, настоящая
гарантия теряет свою силу независимо от того, возвращен нам ее оригинал или
нет.
Настоящая гарантия подчиняется Унифицированным правилам гарантий по
требованию, издание МТП № 458.
____________________________
1
Этот примерный текст предполагает предоставление авансового платежа в размере
10 % от стоимости Контракта за вычетом суммы Текущих расходов и использование
основного варианта, предлагаемого в данной ТДТ в СУК для Статьи 13.2.2 ОУК для
постепенного снижения величины Обоснования Авансового платежа. Если размер
Авансового платежа отличается от 10 % или, если уменьшение суммы обеспечения
происходит по другой схеме, данный параграф потребует соответствующей
переработки и редактирования.
Раздел VII. Образцы форм
[Подпись (подписи)]
659
Раздел VII. Образцы форм
660
7. СЕРТИФИКАТЫ УСТАНОВКИ И ПРИЕМКИ В
ЭКСПЛУАТАЦИЮ
Раздел VII. Образцы форм
661
7.1
Сертификат установки
Дата: [указать дату]
Номер займа/кредита:[указать номер займа или кредита в соответствии с
ПУТ]
ПУТ:[указать название и номер ПУТ]
Контракт:[указать название и номер Контракта]
Куда: [указать наименование и адрес Поставщика]
Уважаемый г-н/г-жа __________!
Согласно Статье 26 (Установка Системы) Общих условий Контракта от
[указать
дату Контракта] между Вами и [указать
наименование
Покупателя](в дальнейшем “Покупатель”) относительно [вставить: краткое
описание Информационной системы], настоящим уведомляем вас о том, что
эта Система (или Подсистема, или ее крупный компонент) была признана
должным образом установленной в указанный далее день.
1.
Описание Системы (или соответствующей Подсистемы или крупного
компонента: [указать описание]
2.
Дата установки: [указать дату]
Несмотря на вышеизложенное, Вы должны в кратчайшие сроки
завершить оставшиеся позиции, перечисленные в Приложении к настоящему
сертификату. Настоящее письмо не освобождает Вас ни от обязанности довести
Систему до стадии приемки в эксплуатацию в соответствии с Контрактом, ни от
выполнения Ваших обязанностей в Гарантийный период.
От имени и по поручению Покупателя
Подпись:
Дата:
Должность [написать: “Директор проекта” или указать должность иного
лица, занимающего более высокое положение в организации Покупателя]
Раздел VII. Образцы форм
7.2
662
Сертификат приемки в эксплуатацию
Дата: [указать дату]
Номер займа/кредита: [указать номер займа или кредита в соответствии с
ПУТ]
ПУТ: [указать название и номер ПУТ]
Контракт: [указать название Системы или Подсистемы и номер
Контракта]
Куда: [указать наименование и адрес Поставщика]
Уважаемый г-н/г-жа __________!
Согласно Статье 27 (Ввод и Приемка в эксплуатацию) Общих условий
Контракта от [указать
дату Контракта] между вами и [указать
наименование Покупателя](в дальнейшем “Покупатель”) относительно
[вставить: краткое описание Информационной системы], настоящим
уведомляем вас, что эта Система (или Подсистема, или крупный компонент,
описанный ниже) успешно прошла указанные в Контракте Приемочные
испытания. В соответствии с условиями Контракта Покупатель настоящим
принимает Систему (или Подсистему, или крупный компонент, описанный
ниже) и, начиная с указанного далее дня, берет на себя ответственность за ее
обслуживание и хранение, а также риск ее утраты.
1.
Описание Системы (или Подсистемы, или крупного компонента):
[указать описание]
2.
Дата приемки в эксплуатацию: [указать дату]
Настоящее письмо не освобождает Вас ни от выполнения оставшихся
обязательств по Контракту, ни от выполнения Ваших обязанностей в
Гарантийный период.
От имени и по поручению Покупателя
Подпись:
Дата:
Должность: [написать: “Директор проекта” или указать должность иного
лица, занимающего более высокое положение в организации Покупателя]
Раздел VII. Образцы форм
663
8. ПОРЯДОК И ФОРМЫ ВНЕСЕНИЯ ИЗМЕНЕНИЯ
Дата: [указать дату]
Номер займа/кредита: [указать номер займа или кредита в соответствии с
ПУТ]
ПУТ: [указать название и номер ПУТ]
Контракт:[указать название Системы или Подсистемы и номер
Контракта]
Общие положения
В настоящем разделе приведены образцы процедур и форм, используемых
для внесения изменений в Систему в процессе выполнения Контракта
согласно положениям Статьи 39 ОУК (Изменение Системы).
Журнал учета Распоряжений об Изменениях
Поставщик должен вести Журнал учета Распоряжений об Изменениях,
отражающий текущий статус Запросов о подготовке предложений об
Изменениях, а также выданных или ожидаемых Распоряжений об
Изменениях. В журнал регулярно вносятся новые записи, чтобы он
соответствовал текущему положению. К ежемесячным отчетам о ходе
работ, которые Поставщик направляет Покупателю, должна прилагаться
копия текущего варианта Журнала учета Распоряжений об Изменениях.
Номера Изменений для ссылок
(1)
Запросы о подготовке предложений об Изменениях (включая Заявки
на подготовку предложения об Изменении) должны иметь
последовательную нумерацию: CR-nnn.
(2)
Предварительные сметы Изменений должны иметь нумерацию: CNnnn.
(3)
Утверждения сметных расчетов должны иметь нумерацию: CA-nnn.
(4)
Предложения об Изменениях должны иметь нумерацию: CP-nnn.
(5)
Распоряжения об Изменениях должны иметь нумерацию: CO-nnn.
ПРИЛОЖЕНИЯ
8.1
Форма Запроса о подготовке предложения об Изменении
8.2
Форма Предварительной сметы Изменения
8.3
Форма Утверждения сметного расчета
8.4
Форма Предложения об Изменении
8.5
Форма Распоряжения об Изменении
8.6
Форма Заявки на подготовку предложения об Изменении
Раздел VII. Образцы форм
8.1
664
Форма Запроса о подготовке предложения об Изменении
(На официальном бланке Покупателя)
Дата: [указать дату]
Номер займа/кредита: [указать номер займа или кредита в соответствии с
ПУТ]
ПУТ:[указать название и номер ПУТ]
Контракт:[указать название Системы или Подсистемы или номер
Контракта]
Куда: [указать наименование и адрес Поставщика]
Кому: [указать Ф.И.О. и должность]
Уважаемый г-н/г-жа __________!
Со ссылкой на вышеупомянутый Контракт просим вас подготовить и
представить в течение [указать количество] дней со дня выпуска настоящего
письма Предложение об Изменении в целях осуществления указанного далее
Изменения, в соответствии с приведенными ниже инструкциями.
1.
Название Изменения: [указать название]
2.
Номер / пересм. Запроса о подготовке предложения об Изменении:
[указать номер]
3.
Инициатор Изменения:
[выбрать Покупатель / Поставщик (по
Заявке на подготовку предложения) и указать название инициатора]
4.
Краткое описание Изменения: [вставить: описание]
5.
Система (или Подсистема, или крупный компонент, которых затрагивает
запрошенное Изменение): [вставить: описание]
6.
Техническая документация и/или чертежи для запроса Изменения:
№ документа или чертежа
Название
7.
Детальные условия или особые характеристики запрошенного Изменения:
[вставить: описание]
8.
Процедуры, которые необходимо соблюдать:
(a)
Ваше Предложение об Изменении должно показать, как запрошенное
Изменение повлияет на Цену Контракта.
(b)
В вашем Предложении об Изменении должно быть указано, сколько
времени потребует внесение запрошенного Изменения и как оно
повлияет на согласованные в рамках Контракта сроки Приемки в
эксплуатацию всей Системы.
Раздел VII. Образцы форм
9.
665
(c)
Если вы считаете, что внесение запрошенного Изменения окажет
отрицательное
влияние
на
качество,
эксплуатационные
характеристики или целостность Системы, дайте подробное
объяснение и, в том числе, опишите другие подходы, которые могут
обеспечить достижение тех же эффектов, что и запрошенное
Изменение.
(d)
Вам также следует указать, как это Изменение повлияет на
численность и состав сотрудников, которые необходимы Поставщику
для выполнения Контракта.
(e)
Вы не должны приступать к выполнению работы, связанной с
запрошенным Изменением, до тех пор, пока мы в письменном виде
не согласимся с тем влиянием, которое это Изменение окажет на
Цену Контракта и График реализации, и не подтвердим его.
В качестве следующего шага вы должны прислать свой ответ, используя
для этого форму Предварительной сметы Изменения, в которой должно
быть указано, сколько будет стоить подготовка конкретного Предложения
об Изменении, описывающего предлагаемый подход к осуществлению
этого Изменения и все его элементы и содержащего сведения,
перечисленные выше в пункте 8 в соответствии с положениями Статьи
39.2.1 ОУК. В вашей Предварительной смете Изменения должны быть
представлены первое приблизительное описание предлагаемого решения и
последствия Изменения для графика и цены.
От имени и по поручению Покупателя
Подпись:
Дата:
Должность: [написать: “Директор проекта” или указать должность иного
лица, занимающего более высокое положение в организации Покупателя]
Раздел VII. Образцы форм
8.2
666
Форма Предварительной сметы Изменения
(На официальном бланке Поставщика)
Дата: [указать дату]
Номер займа/кредита:[указать номер займа или кредита в соответствии с
ПУТ]
ПУТ: [указать название и номер ПУТ]
Контракт: [указать название Системы или Подсистемы и номер
Контракта]
Куда: [указать наименование и адрес Покупателя]
Кому: [указать Ф.И.О. и должность]
Уважаемый г-н/г-жа __________!
Со ссылкой на ваш Запрос о подготовке предложения об Изменении
уведомляем вас о приблизительной стоимости подготовки упомянутого далее
Изменения, как это предусмотрено в Статье 39.2.1 ОУК. Нам известно, что до
того, как мы сможем приступить к фактической подготовке Предложения об
Изменении, включая детальные сметные расчеты самого Изменения, мы
должны получить ваше согласие со стоимостью подготовки Предложения об
Изменении, как это предусмотрено в Статье 39.2.2 ОУК.
1.
Название Изменения: [указать название]
2.
Номер / пересм. Запроса о подготовке предложения об Изменении:
[указать номер]
3.
Краткое описание Изменения (включая предлагаемый
осуществлению Изменения): [вставить: описание]
4.
Влияние Изменения на График реализации (первая оценка): [вставить:
описание]
5.
Первоначальная
смета
первоначальную смету]
6.
Стоимость подготовки Предложения об Изменении:
[указать
стоимость в валютах Контракта], с подробной разбивкой цен, ставок и
объемов, как указано ниже.
осуществления
Изменения:
подход
к
[дать:
От имени и по поручению Поставщика
Подпись:
Дата:
Должность: [написать: “Представитель Поставщика” или указать иное
лицо, занимающее более высокое положение в организации Поставщика]
Раздел VII. Образцы форм
8.3
667
Форма Утверждения сметного расчета
(На официальном бланке Покупателя)
Дата: [указать дату]
Номер займа/кредита:[указать номер займа или кредита в соответствии с
ПУТ]
ПУТ:[указать название и номер ПУТ]
Контракт:[указать название Системы или Подсистемы и номер
Контракта]
Куда: [указать наименование и адрес Поставщика]
Кому:[указать Ф.И.О. и должность]
Уважаемый г-н/г-жа __________!
Настоящим принимаем вашу Смету Изменения и выражаем свое
согласие с тем, чтобы вы приступили к подготовке формального Предложения
об Изменении.
1.
Название Изменения: [указать название]
2.
Номер / пересм. Запроса об Изменении:
запроса]
3.
Номер / пересм. Предварительной сметы Изменения: [указать номер /
пересм. Предварительной сметы]
4.
№ утверждения / пересм. сметы: [указать номер / пересм. сметы]
5.
Краткое описание Изменения: [вставить: описание]
6.
Прочие условия:
[указать
номер / пересм.
В случае если мы решим не давать распоряжения о внесении упомянутого
Изменения, вы будете иметь право на компенсацию расходов, понесенных
в связи с подготовкой Предложения об Изменении в пределах суммы,
рассчитанной для этой цели в Предварительной смете Изменения, как это
предусмотрено в Статье 39 ОУК Общих условий Контракта.
От имени и по поручению Покупателя
Подпись:
Дата:
Должность: [написать: “Директор проекта” или указать должность иного
лица, занимающего более высокое положение в организации Покупателя]
Раздел VII. Образцы форм
8.4
668
Форма Предложения об Изменении
(На официальном бланке Поставщика)
Дата: [указать дату]
Номер займа/кредита: [указать номер займа или кредита в соответствии с
ПУТ]
ПУТ: [указать название и номер ПУТ]
Контракт: [указать название Системы или Подсистемы и номер
Контракта]
Куда: [указать наименование и адрес Покупателя]
Кому: [указать Ф.И.О. и должность]
Уважаемый г-н/г-жа __________!
В ответ на ваш Запрос о подготовке предложения об Изменении №
[указать
номер]
настоящим
представляем
свое
предложение
о
нижеследующем:
1.
Название Изменения: [указать название]
2.
Номер / пересм. Предложения об Изменении: [указать номер / пересм.
предложения]
3.
Инициатор Изменения:
указать название]
4.
Краткое описание Изменения: [вставить: описание]
5.
Основания для Изменения: [указать основания]
6.
Подсистема или крупный компонент Системы, или оборудование, которых
затрагивает запрошенное Изменение: [вставить: описание]
7.
Техническая документация и/или чертежи для запроса Изменения:
№ документа или чертежа
8.
[выбрать: Покупатель / Поставщик и
Название
Оценка
увеличения/снижения
Цены
Контракта
в
результате
предложенного Изменения: [указать сумму в валютах Контракта], с
подробной разбивкой цен, ставок и объемов, как указано ниже.
Общая стоимость Изменения:
Стоимость подготовки настоящего Предложения об Изменении, т.е. сумма,
которая должна быть выплачена в том случае, если Изменение не
Раздел VII. Образцы форм
669
будет принято (с учетом ограничений, предусмотренных в Статье
39.2.6 ОУК)
9.
Дополнительное время, необходимое для доведения Системы до стадии
Приемки в эксплуатацию в связи с Изменением:
[указать
продолжительность в днях / неделях]
10. Влияние на Функциональные гарантии: [вставить: описание]
11. Влияние на условия Контракта: [вставить: описание]
12. Срок действия настоящего Предложения: в течение [указать
количество] дней после получения настоящего Предложения
Покупателем
13. Процедуры, которые необходимо соблюдать:
(a)
Просим сообщить нам о своем согласии, замечаниях или несогласии с
этим подробным Предложением об Изменении в течение [указать
количество] дней после получения данного Предложения.
(b)
Размер любого увеличения и/или снижения стоимости учитывается
при корректировке Цены Контракта.
От имени и по поручению Поставщика
Подпись:
Дата:
Должность: [написать: “Представитель Поставщика” или иное лицо,
занимающее более высокое положение в организации Поставщика]
Раздел VII. Образцы форм
8.5
670
Форма Распоряжения об Изменении
(На официальном бланке Покупателя)
Дата: [указать дату]
Номер займа/кредита: [указать номер займа или кредита в соответствии с
ПУТ]
ПУТ: [указать название и номер ПУТ]
Контракт: [указать название Системы или Подсистемы и номер
Контракта]
Куда: [указать наименование и адрес Поставщика]
Кому: [указать Ф.И.О. и должность]
Уважаемый г-н/г-жа __________!
Настоящим утверждаем Распоряжение об Изменении в целях
выполнения работы, описанной в Предложении об Изменении № [указать
номер], и соглашаемся скорректировать Цену Контракта, Сроки завершения
работ и/или другие условия Контракта, как это предусмотрено в Статье 39
Общих условий Контракта.
1.
Название Изменения: [указать название]
2.
Номер / пересм. Запроса о подготовке предложения о внесении Изменения:
[указать номер / пересм. запроса]
3.
Номер / пересм. Распоряжения об Изменении: [указать номер / пересм.
распоряжения]
4.
Инициатор Изменения:
указать название]
5.
Согласованная Цена Изменения:
№ для ссылки: [указать номер]
[выбрать: Покупатель / Поставщик и
Дата: [указать дату]
[указать сумму в иностранной валюте A], плюс [указать сумму в
иностранной валюте B], плюс [указать сумму в иностранной валюте
C], плюс [указать сумму в местной валюте]
6.
Корректировка срока доведения до стадии Приемки в эксплуатацию:
[указать сумму и описание корректировки]
7.
Прочие эффекты, если таковые имеются:
вставить: описание]
От имени и по поручению Покупателя
Подпись:
Дата:
[написать:
“нет” или
Раздел VII. Образцы форм
671
Должность: [написать: “Директор проекта” или указать должность иного
лица, занимающего более высокое положение в организации Покупателя]
От имени и по поручению Поставщика
Подпись:
Дата:
Должность: [написать: “Представитель Поставщика” или иное лицо,
занимающее более высокое положение в организации Поставщика]
Раздел VII. Образцы форм
8.6
672
Форма Заявки на подготовку предложения об Изменении
(На официальном бланке Поставщика)
Дата: [указать дату]
Номер займа/кредита: [указать номер займа или кредита в соответствии с
ПУТ]
ПУТ:[указать название и номер ПУТ]
Контракт:[указать название Системы или Подсистемы и номер
Контракта]
Куда: [указать наименование и адрес Покупателя]
Кому: [указать Ф.И.О. и должность]
Уважаемый г-н/г-жа _______________!
Настоящим предлагаем рассматривать упомянутую ниже работу как
Изменение Системы.
1.
Название Изменения: [указать название]
2.
№ / пересм. Заявки на подготовку предложения об Изменении: [указать
номер / пересм.]от: [указать дату]
3.
Краткое описание Изменения: [вставить: описание]
4.
Основания для внесения Изменения: [вставить: описание]
5.
Оценка порядка величины: [указать сумму в валютах Контракта]
6.
Влияние Изменения на график: [вставить: описание]
7.
Влияние на Функциональные гарантии (если таковое имеется): [вставить:
описание]
8.
Приложение: [указать названия (если таковые имеются); в противном
случае написать “нет”]
От имени и по поручению Поставщика
Подпись:
Дата:
Должность: [написать: “Представитель Поставщика” или иное лицо,
занимающее более высокое положение в организации Поставщика]