miac.med04.ru¢ехнические требования... · web viewТЕХНИЧЕСКИЕ...
TRANSCRIPT
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
на выполнение работ по развитию региональной информационной системы в сфере здравоохранения
Республики Алтай в части телемедицинских консультаций
г. Горный Алтай2019 г.
Содержание
1. Общие сведения.............................................................................................................3
1.1. Плановые сроки начала и окончания, место выполнения работ..............................3
1.2. Основная нормативная и правовая база для проведения работ................................3
1.3. Цели и задачи развития Системы................................................................................4
1.4. Требования к подсистемам Системы, в отношении которых проводятся работы. 4
2. Подсистема ТМК...........................................................................................................4
2.1. Требования к подсистеме.............................................................................................5
2.2. Требования к интеграционным профилям..................................................................5
2.3. Подсистема "Портал телемедицинских консультаций"............................................5
2.3.1. Работа с заявками..........................................................................................................5
2.3.2. Ведение текстовых и видео чатов................................................................................6
2.3.3. Формирование расписания и учет ресурсов...............................................................6
2.3.4. Формирование консультативного заключения..........................................................6
2.3.5. Администрирование пользователей............................................................................7
2.4. Подсистема "Управление потоками телемедицинских консультаций"...................7
2.4.1. Общие требования.........................................................................................................7
2.4.2. Требования к функциональности................................................................................7
2.5. Аналитические функции..............................................................................................8
2.5.1. Общие требования.........................................................................................................8
2.5.2. Требования к функциональности................................................................................8
3. Подсистема НСИ...........................................................................................................8
3.1. Требования к интеграционным профилям..................................................................9
4. Требования к работам...................................................................................................9
4.1. Прототипирование........................................................................................................9
4.2. Обеспечение лицензионной чистоты..........................................................................9
4.3. Пусконаладочные работы...........................................................................................10
4.4. Ввод в действие...........................................................................................................10
4.5. Требования к сроку выполнения этапов работ.........................................................11
5. Требования к сроку и объему предоставления гарантии качества работ..............12
Приложение I...........................................................................................................................13
Приложение II..........................................................................................................................18
Обозначения и сокращенияАРМ – автоматизированное рабочее место.ГОСТ – государственный стандарт.
ЕГИСЗ – Единая государственная информационная система в сфере здравоохранения.МИС – Медицинская информационная система.МО – Медицинская организация.РС ЕГИСЗ Республики Алтай – региональная сегмент единой государственной
информационной системы здравоохранения Республики Алтай.РФ – Российская Федерация.Система – РС ЕГИСЗ Республики Алтай в части подсистем настоящего технического
задания.СКЗИ - средство криптографической защиты информации.ТМК – телемедицинская консультация.УКЭП - усиленная квалифицированная электронная подпись.ФСБ – Федеральная служба безопасности Российской Федерации.ЭВМ - электронно-вычислительная машина.ЭП - электронная подпись.API - application programming interface - описание способов (набор классов, процедур,
функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой.
FHIR – англ. Fast Healthcare Interoperability Resources (Ресурсы для обмена медицинской информацией) (hl7.org/fhir).
HTTP – англ. Hyper Text Transfer Protocol — протокол прикладного уровня передачи данных.
PDF – англ. Portable Document Format - межплатформенный открытый формат электронных документов.
RESTful – англ. Representational State Transfer – правила построения веб-служб с учётом архитектурного стиля взаимодействия компонентов распределённых в сети.
1. Общие сведения1.1. Плановые сроки начала и окончания, место выполнения работСроки выполнения работ согласно срокам и этапам выполнения работ, указанным в
таблице .Заказчик – Бюджетное учреждение здравоохранения Республики Алтай "Медицинский
информационно-аналитический центр". При наличии технической возможности, работы или часть работ могут быть выполнены по месту нахождения Исполнителя (удалённо) с использованием телекоммуникационных сетей связи по защищенным каналам связи (средства защиты приобретаются Исполнителем за свой счет, доступ обеспечивает Заказчик).
1.2. Основная нормативная и правовая база для проведения работУказ Президента Российской Федерации от 07.05.2018 г. №204 «О национальных целях
и стратегических задачах развития Российской Федерации на период до 2024 года».Приказ Министерства здравоохранения РФ от 30 ноября 2017 г. № 965н «Об
утверждении порядка организации и оказания медицинской помощи с применением телемедицинских технологий».
Постановление Правительства РФ от 6 июля 2015 г. N 676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации".
Федеральный закон от 5 апреля 2013 г. N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд".
Федеральный закон от 29 ноября 2010 года № 326-ФЗ "Об обязательном медицинском страховании в Российской Федерации".
Федеральный закон от 21 ноября 2011 № 323-ФЗ "Об основах охраны здоровья граждан в Российской Федерации".
Федеральный закон от 27.07.2010 г. № 210-ФЗ "Об организации предоставления государственных и муниципальных услуг".
Федеральный закон от 27 июля 2006 г. № 149-ФЗ "Об информации, информационных технологиях и о защите информации".
Федеральный закон от 06 апреля 2011 г. № 63-ФЗ "Об электронной подписи".Федеральный закон РФ "О персональных данных" от 27.07.2006 г. № 152-ФЗ.Распоряжение Правительства РФ от 15.11.2017 г. № 2521-р "Об утверждении перечня
услуг, которые предоставляются с использованием единой государственной информационной системы в сфере здравоохранения".
Постановление Правительства РФ от 12.04.2018 г.№ 447"Об утверждении Правил взаимодействия иных информационных систем, предназначенных для сбора, хранения, обработки и предоставления информации, касающейся деятельности медицинских организаций и предоставляемых ими услуг, с информационными системами в сфере здравоохранения и медицинскими организациями".
Постановление Правительства РФ от 05.05.2018 №555 «О единой государственной информационной системе в сфере здравоохранения».
ГОСТ Р 52976-2008 "Информатизация здоровья. Состав первичных данных медицинской статистики лечебно-профилактического учреждения для электронного обмена этими данными. Общие требования".
ГОСТ Р 52636-2006 "Электронная история болезни. Общие положения."ГОСТ Р ИСО/TС 18308-2008 "Информатизация здоровья. Требования к архитектуре
электронного учета здоровья".Требования нормативной, методической и технической документации, размещенной на
Портале оперативного взаимодействия участников ЕГИСЗ по адресу .Методические рекомендации по обеспечению функциональных возможностей
региональных медицинских информационных систем (РМИС), утвержденных Министерством здравоохранения Российской Федерации от 23.06.2016.
1.3. Цели и задачи развития СистемыРазвитие Системы осуществляется в целях реализации мероприятий единого
цифрового контура здравоохранения, обеспечения проведения телемедицинских консультаций в плановом порядке между медицинскими организациями Республики Алтай.
1.4. Требования к подсистемам Системы, в отношении которых проводятся работы
В рамках выполнения работ должно быть выполнено развитие Системы в части следующих функциональных подсистем Системы:
Подсистема "Телемедицинские консультации" (далее – подсистема ТМК), включает в себя:
Подсистема "Портал телемедицинских консультаций";
Подсистема "Управление потоками телемедицинских консультаций".
Подсистема "Нормативно-справочной информации" (далее – подсистема НСИ).
2. Подсистема ТМКПодсистема должна обеспечить предоставление возможности получения
консультативной медицинской помощи в режиме «врач-врач».Реализация централизованной региональной подсистемы телемедицинских
консультаций должна обеспечить для всех информационных систем здравоохранения Республики Алтай, подключаемых к данной подсистеме, возможность формировать заявки, планировать ресурсы и нагрузку на консультирующих врачей согласно расписанию, обмениваться консультативными заключения без участия пациента в структурированном электронном виде.
2.1. Требования к подсистемеПодсистема должна предоставлять возможность формирования заявки на
телемедицинскую консультацию согласно регламенту работы пунктов (центров) телемедицинских консультаций медицинских организаций Республики Алтай.
Подсистема должна предоставлять пользовательский интерфейс использования собственной функциональности с помощью интернет-портала.
Участникам консультации должна предоставляться возможность ведения текстового и видео чата на портале.
Подсистема должна предоставлять возможность ведения расписания и учета времени врачей, задействованных в телемедицинских консультациях.
Подсистема должна предоставлять возможность предоставления в заявке на телемедицинскую консультацию ссылки на контекстный случай медицинского обслуживания пациента, результат лабораторного или инструментального исследования.
Подсистема должна обеспечивать возможность хранения в электронном виде результатов всех этапов ТМК в течение времени, предусмотренного законодательством для хранения медицинских данных, при условии выделения соответствующих ресурсов под хранение данных Заказчиком.
Подсистема должна обеспечивать печать направлений на телемедицинскую консультацию, с перечнем прилагаемых документов и результатов телемедицинских консультаций.
Подсистема должна быть интегрирована с подсистемой НСИ, автоматически загружать справочники, используемые в ходе сбора и обработки данных телемедицинских консультаций.
2.2. Требования к интеграционным профилямПодсистема должна предоставить интеграционные профили для обеспечения
стандартизованного электронного взаимодействия между информационными системами медицинских организаций об оказанной медицинской помощи согласно Приложению I. Подсистема должна обеспечить валидацию данных, поступающих через интеграционные профили.
Подсистема должна обеспечить RESTful API интеграционные профили на основе стандарта HL7 FHIR для предоставления данных об оказанной медицинской помощи.
2.3. Подсистема "Портал телемедицинских консультаций"Подсистема должна предоставить пользовательские интерфейсы для работы с
подсистемой телемедицинских консультаций.2.3.1. Работа с заявкамиДолжно быть обеспечен доступ к интерфейсам:- Создание новой заявки.
- Формирование консультативного заключения.
- Поиск по заявкам с помощью текстовой поисковой строки и фильтрации по состоянию и по направлению (входящий\исходящий) заявки.
- Просмотр карточки заявки.
- Просмотр прикрепленных результатов лабораторных исследований.
- Переход к просмотру прикрепленных результатов инструментальных исследований.
- Переход к просмотру прикрепленного случая медицинского обслуживания.
- Переход к новому статусу заявки согласно правам пользователя.
2.3.2. Ведение текстовых и видео чатовДолжна быть реализована возможность организовать общение пользователей в
текстовом и видео чатах. При создании новой заявки должен автоматически создаваться текстовый чат для всех
её участников.Изменение статуса заявки должно отображаться в чате, прикрепленном к заявке, в
автоматическом режиме. Должна быть реализована возможность пригласить к текстовому и видео чату новых
участников.При проведении видеоконференцсвязи должна быть реализована возможность
продемонстрировать изображение или фал в формате PDF на общедоступной виртуальной доске. Должна быть реализована возможность масштабировать изображение, добавить на доске текстовый комментарий, воспользоваться маркером.
При подключении в комнату видео чата двух и более участников, автоматически должны запускаться видеозапись. При выходе участников из комнаты видео чата, запись должна останавливаться.
2.3.3. Формирование расписания и учет ресурсовДолжен быть реализован учет плановой, фактической и потенциальной нагрузки на
врачей согласно составленному расписанию по факту его использования. Функциональность должна позволять решать следующие задачи:
- Ведение шаблонов недельного расписания по талонам.
- Ведение шаблонов недельного расписания по принципу простой очереди.
- Составление планового расписания для врачей по имеющимся шаблонам.
- Получение отчета по количеству плановой нагрузки, фактической и потенциальной (остатка).
- Получение информации о заявках, в рамках которых произошло бронирование.
- Получение отчета о нагрузке по врачам в календарном виде: месяц, неделя, день, список.
- Ограничение потока заявок к врачу, в соответствии с установленными МО правилами.
2.3.4. Формирование консультативного заключенияДолжно быть реализовано формирование консультативного заключения в формате
PDF. Должна быть реализована возможность подписать сформированное консультативное
заключение усиленной квалифицированной электронной подписью (УКЭП\ЭП), сформированной по формату CMS (Cryptographic Message Syntax). Для формирования указанных ЭП используются сертификаты, выданные сотрудникам МО (врачам) и непосредственно медицинским организациям. Сертификаты указанных типов должны быть выданы аккредитованными УЦ. Сертификаты должны соответствовать требованиям ГОСТ Р 34.10-2012 (Согласно выписке из документа ФСБ России N 149/7/1/3-58 от 31.01.2014 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования» использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31.12.2018 года не допускается). Квалифицированный сертификат ключа проверки электронной подписи предоставляет Заказчик. В рамках выполнения указанных работ Исполнитель обеспечивает установку (инсталляцию) и наладку СКЗИ на сервере.
При этом Исполнитель должен иметь лицензию на осуществление разработки, производства, распространения шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнение работ, оказание услуг в области
шифрования информации, технического обслуживания шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя), со следующим перечнем выполняемых работ и оказываемых услуг, составляющих лицензируемую деятельность в отношении шифровальных (криптографических) средств: пункт 12 Постановления Правительства РФ от 16.04.2012 № 313. Лицензия предусмотрена Федеральным законом № 99-ФЗ от 04.05.2011 "О лицензировании отдельных видов деятельности".
Заказчику предоставляется копия приведенной лицензии ФСБ Исполнителя.СКЗИ приобретаются Заказчиком за свой счет, передаются Исполнителю для установки
и эксплуатации на серверах Заказчика.Все необходимые регистрации, публикации, доступы, ключи и иные меры,
необходимые для подключения к средам федеральных сервисов, обеспечивает Заказчик при содействии Исполнителя.
2.3.5. Администрирование пользователейДолжен быть реализована возможность администрировать права доступа пользователей
к порталу телемедицинских консультаций. При этом функциональность должна позволять решать следующие задачи:
- Регистрация новой учетной записи администратором или гостем.
- Присвоение и удаление прав пользователю администратором.
- Ведение информационной карточки пользователя.
- Поиск пользователей по списку с возможностью фильтрации.
- Блокировка пользователей администратором.
2.4. Подсистема "Управление потоками телемедицинских консультаций"2.4.1. Общие требованияПодсистема должна обеспечить возможность пользователю описать структуру
хранения и получения данных предметной области используемой в ходе работы над заявками, сформулировать логику и последовательность сбора данных в ходе работы над телемедицинской консультацией.
Подсистема так же должна обеспечить пользователя возможностью сформулировать правила, ограничивающие доступ участников к операциям, предназначенным для проведения телемедицинской консультации.
2.4.2. Требования к функциональностиВ рамках данной задачи, необходимо реализовать следующие функциональные
возможности:- Создание и изменение ресурса (сущности);
- Создание и изменение поля, прикрепленного к ресурсу;
- Создание и изменение составного элемента, прикрепленного к ресурсу;
- Ведение справочника статусов консультаций;
- Создание и изменение маршрута, согласно которому будут обрабатываться заявки на телемедицинские консультации;
- Описание правил перехода к статусу на маршруте: необходимые для заполнения поля выбранных ресурсов, проверки;
- Описание прав доступа пользователей к просмотру заявок;
- Описание прав пользователей к переходам на маршруте;
- Управление правами пользователей к администрированию маршрутов.
Для предоставления доступа к данным по заявкам и реализации описанных в системе бизнес-процессов необходимо реализовать интеграционные методы:
- Получить список маршрутов, по которым пользователь может создать заявку;
- Получить список статусов маршрута;
- Получить список переходов маршрута;
- Получить список правил доступа пользователей на маршруте;
- Осуществить переход, создать заявку;
- Получить список заявок, в которых пользователю доступны для работы;
- Получить список заявок, которые доступны для просмотра;
- Получить текущее состояние заявки.
2.5. Аналитические функции2.5.1. Общие требованияПодсистема должна обеспечить возможность анализа детальной информации на
основании данных полученных об оказанной медицинской помощи, полученных из подсистемы УП.
Уровень детализации данных, находящихся в подсистеме, должен ограничиваться степенью детализации данных в системе-источнике.
2.5.2. Требования к функциональностиНеобходимо реализовать агрегацию статистических данных.В рамках данной задачи, необходимо реализовать получение следующих типовых
отчетов:- Распределение заявок по статусам и профилям;
- Динамика вовлечения в сервис медицинских организаций и работников;
- Распределение заявок по медицинским организациям;
- Соблюдение при выполнении заявок на ТМК временных рамок, заданных Заказчиком (в соответствии с законодательством);
- Распределение пользователей по ролям;
- Активность работы медицинских организаций;
- Активность работы пользователей системы по профилям.
3. Подсистема НСИПодсистема должна обеспечивать хранение актуальных и архивных данных
справочников (НСИ) и обеспечивать доступ к ним для всех подсистем, функционирующих в составе Системы, а также для интегрированных с Системой внешних информационных систем. Должно быть поддержано распространение справочников через интеграционные профили и доступ к подсистеме через пользовательский веб-интерфейс.
3.1. Требования к интеграционным профилямПодсистема должна предоставлять интеграционные профили со следующими
запросами:- запрос справочника – по данному запросу должна предоставляться информация о
справочнике и метаинформации по нему;
- запрос версий справочника – должна предоставляться информация о версиях справочника;
- запрос значений справочника – должна предоставляться код и значение из справочника. Если в запросе указана версия справочника, то подсистема возвращает значения этой версии справочника. Если версия не указана, то подсистема возвращает значения из актуальной версии;
- запрос дополнительной информации о значении (поиск значения) – должна предоставляться дополнительная информация о значении из справочника. Если в запросе указана версия справочника, то подсистема возвращает значения этой версии справочника. Если версия не указана, то подсистема возвращает значения из актуальной версии;
- проверка значения в справочнике – должна предоставляться информация о вхождении запрошенного значения в указанный справочник. Если в запросе указана версия справочника, то подсистема возвращает значения этой версии справочника. Если версия не указана, то подсистема возвращает значения из актуальной версии.
Интеграционные профили должны быть выполнены согласно стандарту HL7 FHIR и соответствовать интеграционным профилям в Приложении II.
4. Требования к работам4.1. ПрототипированиеИсполнитель должен продемонстрировать на своих площадках работающие прототипы
подсистем Управления потокам телемедицинских консультаций, Портала телемедицинских консультаций. Прототипы должны соответствовать интеграционным профилям приложений Технического задания.
Работоспособность прототипов подсистем Системы проверяется путем демонстрации работоспособности интеграционных профилей и пользовательских интерфейсов настоящего Технического задания в программе автоматизированного тестирования.
4.2. Обеспечение лицензионной чистотыДля обеспечения лицензионной чистоты Исполнитель передает Заказчику
неисключительную (простую) лицензию на использование программных средств подсистемы ТМК и подсистемы НСИ (далее – Программ), именуемую далее – Лицензия. Лицензия должна предусматривать использование Программ в составе РС ЕГИСЗ Республики Алтай в пределах их функциональных возможностей по поручению и (или) с ведома Заказчика и в его уставных целях на территории Республики Алтай на неограниченном количестве рабочих станций в течение всего срока действия исключительных прав на Программы.
Лицензия должна быть передана для использования Программ путём их воспроизведения, ограниченного правом инсталляции, копирования и запуска в соответствии с условиями настоящего Технического задания.
Лицензия должна быть передана для использования Программ путём публичного показа (публичное использование Программ и демонстрация в информационных, рекламных и прочих целях).
Лицензия должна действовать в отношении всех элементов, входящих в состав Программ – исходного кода, элементов дизайна (графики, расположения элементов оформления) и т.д.
Лицензия должна предоставляться для использования на неограниченном количестве рабочих станций (рабочие места конечных пользователей). От имени Заказчика конечными пользователями Программ выступают физические лица, непосредственно использующие Программы в пределах их функциональных возможностей по поручению и (или) с ведома Заказчика и в его уставных целях (сотрудники, официальные представители, аудиторы, консультанты и т.п.).
Заказчик должен иметь право предоставлять права на использование Программ в объёме, ограниченном Лицензией (сублицензии), государственным и муниципальным учреждениям и организациям здравоохранения, расположенным на территории Республики Алтай и использующим Систему по в рамках ее функционального назначения.
Программы могут быть переданы Заказчику путем установки (посредством удаленного доступа) на вычислительных ресурсах, предоставленных Заказчиком.
4.3. Пусконаладочные работыИсполнитель проводит установку прикладных программных средств на
вычислительных ресурсах, предоставляемых Заказчиком (серверное и коммутационное оборудование, системное программное обеспечение, системы управления базами данных, программное обеспечение для дистанционного доступа к приложениям).
Если ресурсы являются недостаточными по мнению Исполнителя, то Исполнитель выдает рекомендации по изменению конфигурации вычислительных ресурсов (предоставлению дополнительных мощностей, пропускной способности и т.д.). Затем, после приведения Заказчиком вычислительных ресурсов в необходимое для стабильной и наиболее полной работы функциональности Системы состояние, проводит установку прикладных программных средств.
Пусконаладочные работы должны включать обеспечение подразделений Заказчика инструктивно-методическими материалами (руководство) и инструктаж сотрудников, осуществляющих эксплуатацию Системы, с оформлением ведомости проведения инструктажа.
Инструктаж сотрудников, эксплуатирующих систему, проводится на интеграционной или релиз-кандидат площадке Исполнителя.
4.4. Ввод в действиеВ рамках ввода в действие Исполнитель выполняет наладку прикладных программных
средств подсистем Системы на информационных ресурсах, предоставленных Заказчиком, продуктовая площадка Заказчика. Исполнитель должен загрузить информацию, предоставленную Заказчиком, в базы данных подсистем Системы.
Приемочные испытания должны проводиться Приемочной комиссией на основании Технического задания в соответствии с Программой и методикой приемочных испытаний.
Виды, состав, объем и методы испытаний Системы должны быть изложены в Программе и методике испытаний, разрабатываемой в составе рабочей документации Исполнителем и согласуемой Заказчиком не более чем за 3 (Три) рабочих дня до проведения испытаний.
Статус и состав Приемочной комиссии должны быть определены Заказчиком не более чем за 3 (Три) рабочих дня до начала проведения испытаний.
В состав Приемочной комиссии включаются представители Заказчика и Исполнителя. Представители Исполнителя могут присутствовать на приемочных испытаниях, при наличии технической возможности, по месту нахождения Исполнителя (удалённо) с использованием телекоммуникационных сетей связи, доступ обеспечивает Заказчик. Также, по необходимости, Заказчиком могут быть привлечены сторонние эксперты.
В рамках проведения испытаний Системы на оборудовании Заказчика Исполнитель должен провести испытания согласно разработанной им Программе и методике испытаний, согласованной Заказчиком, и продемонстрировать работоспособность функциональности подсистем Системы путем демонстрации работоспособности интеграционных профилей подсистем настоящего Технического задания в программе автоматизированного тестирования.
Приемка в постоянную эксплуатацию осуществляется Заказчиком с оформлением протокола проведения приемочных испытаний.
Риски случайной гибели или случайного повреждения результата работ, а также бремя его содержания переходят от Исполнителя к Заказчику с даты окончания выполнения работ, а в случае обнаружения в ходе приемки работ недостатков – с даты устранения
Исполнителем всех выявленных недостатков. Факт окончания выполнения работ, а также устранение недостатков выполненных работ фиксируется Сторонами актом сдачи-приемки выполненных работ, подписанным уполномоченными представителями Исполнителя и Заказчика.
4.5. Требования к сроку выполнения этапов работДолжны быть соблюдены этапы и сроки выполнения работ, указанные в таблице .
Таблица 1 – Перечень этапов и сроков выполнения работ№ этапа
Наименование этапа
Наименование отчетных
документов
Срок Стоимость% от общей стоимости контракта
В том числе НДС
I Прототипирование Акт сдачи-приемки выполненных работ
Не более, чем 5 рабочих дней с момента подписания Контракта
___ руб. ___ коп.
(не более 5%)
___ руб. ___ коп.
II Обеспечение лицензионной чистоты (передача неисключительных прав)
1. Лицензионное соглашение2. Акт приема-передачи неисключительных прав
Не более, чем 5 рабочих дней с момента выполнения I этапа
___ руб. ___ коп.
(не более 30%)
Не облагается на пп. 26 п. 2 ст. 149 НК РФ
III Пусконаладочные работы
1. Инструктивно-методические материалы (руководство).2. Ведомость проведения инструктажа.3. Акт сдачи-приемки выполненных работ
Не более, чем 10 рабочих дней с момента выполнения II этапа
___ руб. ___ коп.
(не более 30%)
___ руб. ___ коп.
IV Ввод в действие 1. Программа и методика приемочных испытаний.2. Протокол проведения приемочных испытаний.3. Акт сдачи-приемки выполненных работ
Не позднее 15 декабря 2019 года
___ руб. ___ коп.
(не менее 35%)
___ руб. ___ коп.
Документы, предоставляемые в электронном виде, должны быть выполнены в форматах PDF, MS Word или аналогичных открытых форматах.
5. Требования к сроку и объему предоставления гарантии качества работГарантийный срок на выполненные работы должен составлять 12 месяцев.
Гарантия должна быть предоставлена на выполненные работы на весь гарантийный срок с момента подписания акта сдачи-приемки выполненных работ. Исполнитель должен обеспечить устранение за свой счет всех выявленных Заказчиком и направленных Исполнителю ошибок (невыполнение или некорректное выполнение функций, предусмотренных Техническим заданием).
Приложение Iк Техническому заданию
Интеграционные профили подсистемы ТМК
Описание взаимодействия с сервисомПодсистема ТМК предназначен для ведения, хранения, поиска и выдачи сведений по
телемедицинским консультациям в рамках региона. Подсистема обеспечивает:1. Централизованный учет заявок на телемедицинские консультации.
2. Централизованный учет результатов телемедицинских консультаций.
3. Получение заявок на телемедицинские консультации и передача их по запросу.
4. Передача статуса и актуальный набор сведений заявки по запросу.
Обмен данными между МИС МО и подсистемой ТМК осуществляется в рамках следующих сценариев:
1. Получение идентификаторов возможных начальных состояний процесса (создания заявки).
2. Запуск нового процесса по указанному маршруту.
3. Получение всех процессов (заявок).
4. Получение процесса (заявки) по идентификатору.
5. Получение объекта контекста процесса. Получение набора данных собранных в заявке.
6. Получение идентификаторов следующих возможных состояний процесса.
7. Осуществление перехода в указанное состояние в рамках процесса.
Базовая схема информационного взаимодействия приведена на рисунке 1.
Рисунок 1 - Базовая схема информационного взаимодействия
Получение идентификаторов возможных начальных состояний для процесса
Данный метод предназначен для получения идентификаторов возможных начальных состояний для процесса.
Описание параметров ответа
№ п/п Тип Обязательность Описание1. Строковый Обязательно Результат2. Строковый Обязательно Статус ответа3. Числовой Обязательно Код ошибки4. Строковый Обязательно Сообщение
Запуск нового процесса по указанному маршруту
Данный метод предназначен для запуска нового процесса по указанному маршруту.
Описание параметров запроса
№ п/п Тип Обязательность Описание1. Строковый Обязательно Идентификатор маршрута 2. Строковый Обязательно Название заявки3. Строковый Обязательно Ссылка на хранилище объектов
контекста для предметной области4. Строковый Обязательно Начальный статус5. Структура Обязательно Набор данных для создания заявки6. Структура Обязательно Набор данных для проверки
доступности операции
Описание параметров ответа
№ п/п Тип Обязательность Описание1. Строковый Обязательно Идентификатор маршрута 2. Строковый Обязательно Идентификатор заявки3. Строковый Обязательно Идентификатор статуса4. Строковый Обязательно Результаты проверок5. Строковый Обязательно Статус ответа6. Числовой Обязательно Код ошибки7. Строковый Обязательно Сообщение
Результат проверок
№ п/п Тип Обязательность Описание1. Логический Обязательно Статус проверки
2. Строковый Обязательно Сообщение
Получение всех процессов
Данный метод предназначен для получения всех процессов.
Описание параметров ответа
№ п/п Тип Обязательность Описание
1. Строковый Обязательно Идентификатор процесса2. Строковый Обязательно Наименование процесса3. Строковый Обязательно Идентификатор маршрута4. Строковый Обязательно Ссылка на хранилище объектов контекста
для предметной области5. Строковый Обязательно Идентификатор сущности6. Строковый Обязательно Текущий идентификатор статуса
Получение процесса по идентификатору
Данный метод предназначен для получения процесса по идентификатору.
Описание параметров ответа
№ п/п Тип Обязательность Описание1. Строковый Обязательно Идентификатор процесса2. Строковый Обязательно Наименование процесса3. Строковый Обязательно Идентификатор маршрута4. Строковый Обязательно Ссылка на хранилище объектов контекста
для предметной области5. Строковый Обязательно Идентификатор сущности6. Строковый Обязательно Текущий идентификатор статуса
Получение объекта-контекста процесса
Данный метод предназначен для получения объекта-контекста процесса.
Описание параметров ответа
№ п/п Тип Обязательность Описание1. Структура Обязательно Результат2. Строковый Обязательно Статус ответа3. Числовой Обязательно Код ошибки4. Строковый Обязательно Сообщение
Получение идентификаторов следующих возможных состояний для процесса
Данный метод предназначен для получения идентификаторов следующих возможных состояний для процесса.
Описание параметров ответа
№ п/п Тип Обязательность Описание1. Строковый Обязательно Результат2. Строковый Обязательно Статус ответа3. Числовой Обязательно Код ошибки4. Строковый Обязательно Сообщение
Осуществление перехода в указанное состояние в рамках указанного процесса
Данный метод предназначен для осуществления перехода в указанное состояние в рамках указанного процесса.
Описание параметров запроса
№ п/п Тип Обязательность Описание1. Строковый Обязательно Идентификатор заявки2. Строковый Обязательно Идентификатор статуса3. Структура Обязательно Набор данных для создания заявки4. Структура Обязательно Набор данных для проверки доступности
операции
Описание параметров ответа
№ п/п Тип Обязательность Описание1. Строковый Обязательно Идентификатор маршрута2. Строковый Обязательно Идентификатор заявки3. Строковый Обязательно Идентификатор статуса4. Строковый Обязательно Результаты проверок5. Строковый Обязательно Статус ответа6. Числовой Обязательно Код ошибки7. Строковый Обязательно Сообщение
Результат проверок
№ п/п Тип Обязательность Описание1. Логический Обязательно Статус ответа
2. Строковый Обязательно Сообщение
Приложение IIк Техническому заданию
Интеграционные профили подсистемы НСИ
Описание протокола взаимодействия
Общая информацияИнформационный обмен осуществляется в соответствии с международным стандартом,
определяющим формат хранения / обмена / предоставления медицинской информации в электронном виде и включающий в себя спецификацию клиент-серверного взаимодействия.
В качестве протокола взаимодействия используется архитектурный стиль взаимодействия компонентов распределённого приложения в сети.
Авторизация в подсистеме НСИДля обращения к подсистеме НСИ необходимо указать в параметре секции сообщения
авторизационный ключ (токен).Авторизационный ключ системе-клиенту подсистеме НСИ выдается администратором
интеграционной платформы.По умолчанию для всех потребителей в подсистеме НСИ действуют полномочия на
получения справочной информации публичных справочников. Для получения информации приватных справочников необходимы расширенные полномочия, настраиваемые администратором подсистемы НСИ.
Формат обменаВозможные форматы обмена с подсистемой НСИ: json, xml.Если формат не задан явным образом, то по умолчанию подсистема НСИ формирует
ответы в формате xml.Подсистема НСИ первоначально вычисляет и формирует результат в формате json.
Затем, если в запросе явно задан формат xml, производится преобразование типа json в xml. Поэтому в запросах к подсистеме НСИ рекомендуется использовать формат json.
Операции со справочникамиПодсистема НСИ поддерживает следующие операции:1. Получение данных паспорта справочника;
2. Получение версий справочника;
3. Получение справочных данных;
4. Получение дополнительной информации о значении;
5. Проверка значения в справочнике.
Описание операций подсистемы НСИ
Получение данных паспорта справочникаПолучение информации о справочнике осуществляется с помощью запроса. Параметры
ответа приведены в таблице . Таблица 2 – Параметры запроса
Тип ОписаниеАвторизационный ключ Идентификатор справочника в подсистеме НСИДата и время Дата-время последнего обновленияСтрока Адрес положения справочника в ИнтернетеЦелочисленный тип данных Значение актуальной версии справочника Строка Издатель справочника
Получение версий справочникаПолучение версий справочника осуществляется с помощью запроса. Параметры ответа
приведены в таблице . Таблица 3 – Параметры ответа
Тип ОписаниеСтрока Наименование параметра (результат)Строка Номера версий справочника и даты создания версий в формате «версия
справочника (дата формирования), версия справочника (дата формирования)…»
Получение справочных данныхПолучение справочных осуществляется с помощью запроса. Параметры запроса
представлены в таблице . Таблица 4 – Параметры запроса
Тип Обязательность ОписаниеСтрока Обязательно Значение кодовой системы (положения справочника в
Интернете)Строка Необязательно Номер версии справочника. Если номер версии не
указан, то возвращаются значения из актуальной версии
Параметры ответа приведены в таблице . Таблица 5 – Параметры ответа
Тип ОписаниеАвторизационный ключ
Идентификатор справочника в подсистеме НСИ
Дата и время Дата-время последнего обновленияСтрока Адрес положения справочника в Интернете Строка Значение актуальной версии справочника Строка Код значенияСтрока Значение, соответствующее кодуСтрока Номер версии значения
Передаются дополнительные атрибуты записей помимо «Код» и «Вывод». Каждый атрибут описывается параметрами «Код» и «Вывод»
Получение дополнительной информации о значении (записи справочника)Получение дополнительной информации о значении (поиск значения) осуществляется с
помощью запроса. Параметры запроса представлены в таблице .Таблица 6 – Параметры запроса
Тип Обязательность ОписаниеСтрока Обязательно Значение кодовой системы (Адрес положения
справочника в Интернете)Строка Необязательно Номер версии справочника. Если номер версии не указан,
то возвращаются значения из актуальной версииСтрока Обязательно Код значения в справочнике
Параметры ответа приведены в таблице .
Таблица 7 – Параметры ответаТип Описание
Строка Наименование дополнительного параметра для запрошенного значения справочника
Строка Значение дополнительного параметра
Проверка значения в справочникеПроверка значений в справочнике осуществляется с помощью запроса. Параметры
запроса представлены в таблице .Таблица 8 – Параметры запроса
Тип Обязательность ОписаниеСтрока Обязательно Значение кодовой системы (адрес положения справочника
в Интернете)Строка Необязательно Номер версии справочника. Если номер версии не указан,
то возвращаются значения из актуальной версииСтрока Обязательно Код значения в справочнике
Параметры ответа приведены в таблице .Таблица 9 – Параметры ответа
Тип ОписаниеСтрока Наименование параметра (результат)Строка Результат проверки (да / нет)
Вычисление соответствия кодовых значений заданных справочников Для перекодирования кодовых значений одного справочника в кодовые значения,
соответствующие другому справочнику, возможно использования метода вычисления соответствия кодовых значений. Получение соответствий кодовых значений заданных справочников происходит с помощью запроса.
Перечень параметров для получения соответствия кодовых значений заданных справочников приведен в таблице .
Таблица 10 – Параметры запросаТип Обязательность Описание
Строка Обязательно Публичные идентификатор справочника 1 (один из пары по поиску соответствий)
Строка Обязательно Кодовое значение из справочника 1Строка Обязательно Публичные идентификатор справочника 2 (один из
пары по поиску соответствий)Логический тип данных
Необязательно Признак поиска обратного соответствия:«Нет» – поиск соответствия кодового значения из справочника 1 в справочнике 2;«Да» - поиск соответствия кодового значения из справочника 2 в справочнике 1;По умолчанию используется значение «Нет»
Дата и время Необязательно Поиск соответствий на конкретную дату: поиск в исторически данных справочника соответствия кодовых значений
Объект Необязательно Описание справочника, содержащего данные соответствия. Обозначение справочника представляется в формате «Система»: «Идентификатор», где «Идентификатор» - публичный идентификатор справочника соответствия.Указание публичного идентификатора справочника
Тип Обязательность Описаниеобязательно в том случае, если в системе имеется несколько справочников соответствия кодовых значений пары справочников*
* Примечание: в общем случае в системе имеется однозначное соответствие кодовых значений пары справочников. Однако могут быть ситуации, когда в целях систем-потребителей составляется несколько справочников соответствия кодовых значений одной и той же пары справочников. В данном случае возможно управлять получением соответствия указанием публичного идентификатора справочника соответствия (идентификатором справочника), по которому необходимо вычислить соответствие.
В результате вычисления соответствия кодовых значений может быть вычислено одно кодовое значение, соответствующее запрашиваемому коду, либо несколько кодовых значений. Результаты получения таких соответствий называют однозначным и множественным соответствиями.
Параметры ответа приведены в таблицах - . Таблица 11 – Параметры ответа (однозначное соответствие)
Тип ОписаниеЛогический тип данных
Результат поиска:«Да» – соответствие найдено;«Нет» – соответствие не найдено
Строка Найденное кодовое значение соответствияТаблица 12 – Параметры ответа (множественное соответствие)
Тип ОписаниеЛогический тип данных
Результат поиска:«Да» – соответствие найдено;«Нет» – соответствие не найдено
Массив Массив из пар «Код»-«Значение».Значение – найденные кодовые значения соответствия