Tags: Электронная регистратура

О новых нормативных требованиях в части интеграции региональных сегментов ЕГИСЗ с «Моим здоровьем»

Дмитрий Медведев подписал распоряжение №2521-р от 15.11.2017 года, где утверждён перечень услуг в сфере здравоохранения, которые должна обеспечить ЕГИСЗ на едином портале гос. услуг (ЕПГУ). Рассматриваем, какие именно обязательства теперь стоят перед операторами и разработчиками соответствующих компонентов региональных сегментов ЕГИСЗ http://www.kmis.ru/site.nsf/apages/epgu_11.htm

О возможности записи к врачу через Интернет и последних изменениях по этому вопросу

Недавно Минздрав потребовал от регионов доработать интеграцию региональных «Электронных регистратур» с сервисом «Мое здоровье» ЕПГУ, убрав возможность пациенту выбрать любую медицинскую организацию и ограничив этот выбор только той МО, к которой пациент прикреплен. Разбираемся с этим требованием в блоге компании К-МИС: http://www.kmis.ru/site.nsf/apages/er_08_2017.htm

История и показатели развития "Единой электронной регистратуры ЯНАО"

Так получается, что когда речь заходит об истории какого-то проекта или внедрения медицинской информационной системы, то чаще всего мы читаем (или рассказываем сами) скорее оценочные суждения, говорим о повышении качества медицинских данных или удобстве формирования отчетов и т.д. Мы редко оперируем какими-то конкретными данным: сколько было оказано тех или иных услуг в электронном виде, какова динамика жалоб на систему, какой росто числа пользователей и т.д.

В этом смысле - МИАЦ ЯНАО подготовил действительно классные фактографические показатели развития собственного сервиса "Единая электронная регистратура ЯНАО" и достаточно подробно рассказал о том, с чего стартовал проект, какие сложности были преодолены и на какие результаты удалось выйти специалистам МИАЦ совместно со своими пользователями. Подробности и куча разных интересных графиков и диаграмм тут: http://www.kmis.ru/site.nsf/pages/22.06.2017.htm

О развитии региональных сегментов ЕГИСЗ и работе личного кабинета пациента «Мое здоровье» на ЕПГУ

31 марта 2017 г. Минздрав РФ опубликовал на портале оперативного взаимодействия участников ЕГИСЗ материалы «О статусе реализации раздела «Моё здоровье» на ЕПГУ» - http://portal.egisz.rosminzdrav.ru/materials/521. Данные документы были подготовлены к заседанию подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности, http://minsvyaz.ru/ru/activity/advisories/16/

В опубликованных справочных материалах сообщается, что в личном кабинете пациента «Моё здоровье» на ЕПГУ в течение 2017-2018 годов будут реализованы 10 сервисов в сфере охраны здоровья.

Первая очередь, предусматривающая запуск «Личного кабинета», должна состоятся до конца мая 2017 г. В рамках нее на ЕПГУ должны появится следующие сервисы для граждан:

  • Запись на прием к врачу;

  • Вызов врача на дом;

  • Получение сведений об оказанной медицинской помощи;

  • Получение сведений о полисе обязательного медицинского страхования и страховой медицинской организации;

  • Получение сведений о прикреплении к медицинской организации.

До конца декабря 2017 года в рамках второй очереди должны быть реализованы следующие сервисы:

  • Просмотр электронных медицинских документов на основании данных из «Федеральной интегрированной электронной медицинской карты»

  • Получение справки об оказанных медицинских услугах и их стоимости;

  • Оформление полиса обязательного медицинского страхования;

  • Оценка удовлетворенности качеством работы медицинских организаций;

  • Запись на профилактические (плановые) медицинские осмотры.



Более подробное описание доступно тут: http://www.kmis.ru/site.nsf/apages/epgu_04_2017.htm

О развитии ЕПГУ и будущем региональных «Электронных регистратур»

Для региональных сервисов записи к врачу через Интернет, чаще называемых «Электронными регистратурами», предстоят серьезные корректировки в своем развитии.

26 августа 2016 г. состоялось очередное заседание «Подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности» под председательством зам. министра связи А.О. Козырева. Протокол заседания №328пр доступен по адресу http://minsvyaz.ru/uploaded/files/26082016-328pr.pdf.

Одной из важных тем, которая обсуждалась на этом совещании, стала оптимизация государственной услуги «Запись на прием к врачу». По данному вопросу выступила директор департамента информационных технологий и связи Минздрава (ДИТиС) Е.Л. Бойко, а также представитель Минкомсвязи А.В. Павлович. Результатом работы комиссии стало (раздел V, п.1-п.5):


  1. Одобрение предложенного плана мероприятий по оптимизации предоставления данной услуги, в том числе создание по инициативе Минздрава раздела «Мое здоровье» на ЕПГУ (об этом, например, можно почитать тут: http://riaami.ru/read/na-portale-gosuslug-poyavitsya-lichnyj-kabinet-polzovatelya-moe-zdorove)

  2. Поручение Минкомсвязи совместно с Минздравом разработать критерии, с помощью которых будет определяется условие сохранения региональных порталов записи к врачу через Интернет. Срок - до 30.10.2016.

  3. Направление регионам рекомендации по подключению услуги «Запись на прием к врачу» на ЕПГУ (об этом ранее уже было отдельное соответствующее письмо Минздрава № 18-1/1202 от 28.07.2016, см. http://www.kmis.ru/site.nsf/apages/koncentrator_fer.htm)


Кроме этого, обсуждались различные вопросы, так или иначе связанные с развитием «электронного правительства). В контексте «Электронных регистратур» можно отметить следующие моменты:


  1. Необходимо обратить внимание на уровень ошибок в работе информационных систем и обеспечивать определенный уровень качества их работы, указанный в «Требованиях к качеству функционирования информационных систем, используемых при предоставлении государственных и муниципальных услуг в электронном виде» (раздел I, п.10). Документ доступен по адресу http://d-russia.ru/wp-content/uploads/2016/03/trebovania_k_kachestvu_is.docx

  2. Регионам рекомендовано усилить работу по достижению 50% зарегистрированных в ЕСИА граждан, что предусматривается Указом Президента РФ №601 «Об основных направлениях совершенствования системы государственного управления» от 07.05.2012 (раздел I, п.11 и п.12, раздел II и раздел VI). Документ доступен тут: https://rg.ru/2012/05/09/gosupravlenie-dok.html


В целом сейчас федеральные органы исполнительной власти (ФОИВ) в том, что касается «электронного правительства», продвигают различные концепции и идеи, так или иначе направленные на повышение эффективности гос. услуг. Это и развитие МФЦ, это продвижение принципа «одного окна», это и в том числе исключение дублирования затрат, особенно при внедрении новых государственных услуг и сервисов. Считается, что новые гос. услуги должны сразу появляется на ЕПГУ и не должны дублироваться на региональных порталах – это удобно гражданам и разумно с точки зрения экономии государственных средств. Более того, консолидация услуг на ЕПГУ позволяет лучше обеспечивать их качество и доступность за счет централизации и функционирования базовых сервисов (например, разумнее использовать один общефедеральный сервис авторизации, чем поддерживать «зоопарк» из 85 их региональных вариантов), лучше контролировать доступность региональных систем и корректность их работы и т.д. В целом, можно сказать, что централизация в одном месте (на ЕПГУ) всех государственных услуг вместо того, чтобы развивать их на региональных порталах – это сформировавшийся тренд и его постепенно, без революций и непродуманных резких шагов, наши ФОИВ и продвигают.

С точки зрения услуги «Запись на прием к врачу» она в настоящее время доступна на ЕПГУ лишь в 26 регионах (30%). Минздрав совместно с Минкомсвязью планируют исправить это и обеспечить к 2018 г. доступность данной услуги во всех 85 субъектах РФ (в следующем 2017 г. - 65 субъектов 75%).

При этом в Минздраве прекрасно понимают, что сейчас во многих регионах данный сервис работает и вполне успешно. В их создание и развитие вложены колоссальные средства, граждане внутри регионов уже привыкли к своим местным «Электронным регистратурам». Перевести данную услугу на ЕПГУ и при этом «убить» местный региональный сервис – не самая лучшая затея, это может вызвать недовольство населения и сопротивление местных властей. Более того, сейчас все вопросы интеграции различных МИС МО с региональной «Электронной регистратурой», техническое обеспечение и сопровождение такой системы, взаимодействие с разработчиками МИС и т.д. решаются внутри региона самостоятельно. Если все это запретить, то может получиться так, что местная система перестанет работать, а вот продолжил ли хотя бы на том же уровне оказываться данная услуга на ЕПГУ – большой вопрос.

Учитывая все это, Минздрав совместно с Микомсвязью предлагаю развивать услугу «Запись на прием к врачу» по следующему сценарию: для того, чтобы записаться к врачу через Интернет, гражданин должен иметь учетную запись в ЕСИА, зайти на ЕПГУ по адресу https://www.gosuslugi.ru/ и выбрать нужный регион. Далее ЕПГУ будет взаимодействовать с соответствующей ведомственной информационной системой (ВИС), в качестве которой на данное время будет выступать региональный портал записи к врачу (региональная «Электронная регистратура»). Если в регионе нет такого решения, можно использовать компонент ЕГИСЗ «Федеральная электронная регистратура» (ФЭР). Хранение расписания врачей, их обработку, интеграцию с МИС МО и реализацию необходимой бизнес-логики должна выполнять именно «Электронная регистратура», которая должна уметь обменивается с ЕПГУ необходимой информацией через протокол информационного взаимодействия, реализованный в «Концентраторе услуг ФЭР», http://www.kmis.ru/site.nsf/apages/koncentrator_fer.htm.

Для того, чтобы выйти на эту модель работы, региональные власти должны усовершенствовать имеющиеся у них сервисы «Электронная регистратура». Для этого предложен соответствующий «План мероприятий», представленный в приложении №6 протокола №328пр. Согласно этому плану, в 2017 г. Минкомсвязь совместно с субъектами РФ должна подключить к ЕПГУ дополнительно 44 региона, а в 2018 г. – оставшиеся 20 субъектов. Для того, чтобы региональная «Электронная регистратура» могла совместно работать с ЕПГУ, в нее должна быть добавлена интеграция с «Концентратором услуг ФЭР», а также возможность авторизации граждан через ЕСИА.

Полный текст с дополнительными материалами доступен тут: http://www.kmis.ru/site.nsf/apages/epgu_er.htm

Об интеграции с «Концентратором ФЭР»

28.07.2016 Минздравом было разослано письмо № 18-1/1202, в котором Департамент информационных технологий и связи попросил региональные ОУЗ рассмотреть возможность подключения региональной медицинской информационной системы (РМИС) каждого субъекта к «Концентратору услуг ФЭР» (далее – Концентратор).

Концентратор представляет из себя компонент Федеральной электронной регистратуры (ФЭР), предназначенный для предоставления услуги «Запись на прием к врачу» через Единый портал государственных услуг (ЕПГУ, https://www.gosuslugi.ru/).

Ранее задачей разработчиков региональных электронных регистратур была интеграция с ФЭР, которая позволяла загружать в ФЭР сведения о расписании приема специалистов и принимать заявки от пациентов на прием к врачу через Интернет в том случае, если запись пациентов на прием велась через ФЭР. В связи с развитием ЕПГУ в «Федеральной электронной регистратуре» пришлось изменить архитектурный подход и выделить специальный компонент – «Концентратор», который в конце 2015 г. прошел опытную эксплуатацию. Согласно пояснениям Минздрав, именно Концентратор будет в дальнейшем единой точкой интеграции региональных медицинских информационных систем (РМИС) всех субъектов РФ с ЕПГУ.

Побробнее: http://www.kmis.ru/site.nsf/apages/koncentrator_fer.htm

Электронные регистратуры России: сводный перечень

На следующей неделе начнется ежегодная конференция и выставка Medsoft 2015. В рамках нее планируется выступление по поводу электронных регистратур. Для этого удалось собрать интересную статистику по всем регионам: где какое решение используется, какой уровень развития этого решения, сколько МО предоставляю информацию о себе на портале записи к врачу через Интернет и т.д. Файл с аналитикой выложил на Госбук по следующему адресу: http://www.gosbook.ru/node/89428

Мы написали «Электронную регистратуру». Заново

Компания «Комплексные Медицинские Информационные Системы» (К-МИС) анонсирует выпуск нового программного продукта - «Электронная регистратура 3.0» (ЭР 3.0), которая в настоящее время введена в промышленную эксплуатацию в Ямало-ненецком автономном округе (ЯНАО), http://er.yamalzdrav.ru.
Расскажу немного об этом проекте, поскольку для Компании он является очень важным, а с точки зрения примененных технологий разработки - совершенно новым.

Не секрет, что все наши программные продукты мы строим на платформе IBM Notes/Domino – средстве групповой работы и автоматизации электронного документооборота. Раньше она называлась IBM Lotus, но сейчас от слова «Lotus» IBM избавилось. Это клиент-серверное решение корпорации IBM очень хорошо известно, оно насчитывает миллионы клиентов по всему миру и достаточно распространено в корпоративной среде. На платформе Notes/Domino построена наша комплексная медицинская информационная система «КМИС», решение для создания региональных сегментов ЕГИСЗ – «КМИС.РИР», а также «Электронная регистратура» версии 2.6.х (ЭР 2.6.x).

Традиционный 2-х звеный подход создания информационных систем на основании сервера (СУБД) и толстого клиента, который является основной наших информационных систем, в целом достаточно хорошо известен, понятны его сильные и слабые стороны, понятны плюсы и минусы создания и поддержки таких продуктов.

Сохраняя традиционную для нас стратегию развития уже существующих программных решений, мы присматривались к относительно новому для нас направлению – это создание современных web-приложений, ориентированных на высоконагруженные задачи, работу исключительно в web-браузере, создание 3-х звенных приложений на базе открытых стандартов – Java, HTML5, CSS3 и т.д. Вместе с этим – просто взять и переписать существующие медицинские информационные системы с применяемого подхода на нечто новое рассматривается нами как очень затратный и высокорисковый поступок. Такой переход привел бы к замораживаю развития функциональности как минимум на полгода-год, которые потребовались бы на переписывание уже существующей реализации с платформы Notes/Domino на нечто новое. Более того, мы понимали, что было бы неэффективно пытаться переориентировать существующую команду разработчиков на новые инструменты разработки, т.к. компания не могла позволить себе заморозить уже реализуемые проекты. В таких условиях – или учиться и новые технологии осваивать, или существующие продукты развивать и поддерживать. Совместить и то и другое – значит погнаться за двумя зайцами. Поэтому, выбора то особого тут и не было.

В связи с этим в 2011 г. в компании было принято решение создать совершенно новое подразделение, которое бы решало задачи изучения новых для нас подходов в разработке сложных информационных систем. Почти год ушел на подготовку проекта: консолидацию необходимых финансовых ресурсов, поиск людей, вынашивание идей и задач. В результате в конце 2012 г. была собрана специальная команда, которая и приступила к непосредственной работе по проектированию и созданию продукта в январе 2013 г. Первые несколько месяцев ушли на чисто НИОКРовские задачи: изучение нового программного обеспечения и технологий, посещение специализированных мероприятий типа Highload, изучение различных подходов и опыта создания высоконагруженных решений типа «ВКонтакте» и т.д. За это время мы накопили уникальный для компании опыт и понимание новых возможностей.

Параллельно с этим компания также изучала, систематизировала и оценивала те сложности и проблемы, которые мы накопили за время эксплуатации существующих систем. В какой-то момент времени и пришло понимание, какова должна быть с точки зрения разработки будущая «Электронная регистратура».

Новое решение – это полностью написанная с нуля платформа, архитектура которой спроектирована таким образом, чтобы выдерживать тысячи подключений и огромные объемы накапливаемых данных. Она включает такие компоненты, как балансировщики нагрузки, координаторы запросов, сверхбыстрый умный кеш, функциональные web-приложения, объединенные по группам задач и распределенные по web-серверам, децентрализованное хранилище данных и выделенные сервера для подготовки и формирования статистической отчетности. Выбранный подход и архитектурные решения основаны на современной «облачной» парадигме разработки и доставки приложения заказчику.

В качестве платформы разработки мы применяем Java, хотя этот выбор не был простым – за период НИОКРа команда изучила разные варианты, включая PHP, Python, Ruby on Rails и т.д. Большинство внутренних интерфейсов реализованы в виде одностраничных приложений с помощью AngularJS. В качестве IDE лучшей для нас оказалась IntellijIDEA. Web-сервера – nginx, сервера приложений – GlassFish, СУБД – PostgresSQL, кеш – Redis, очереди - RabbitMQ. Плюс – применяются новые методы автоматизированной сборки и тестирования системы, планирование работы программистов и т.д.

Создание новой «Электронной регистратуры» заняло порядка 6 месяцев. Такой большой срок потребовался сразу по нескольким причинам. Во-первых, команда, которая создавала систему, изначально не знала функциональности существующего продукта. Ее задачей была специализация именно на изучении новых средств разработки и методиках построения современных высоконагруженных систем. Поэтому часть времени ушло на внутреннее изучение существующей ЭР 2.6.х и перенос ее функциональности в новое решение, т.е. – фактически - написание «Электронной регистратуры» с нуля. Во-вторых, новая ЭР 3.0 совершенно иначе устроена внутри с точки зрения реализации. Все ее компоненты стандартизованы и общаются друг с другом, а также с внешними медицинскими информационными системами уровня МО на базе API, прямого обращения к БД и объектам новой ЭР у ее компонентов нет. В-третьих, пришлось потратить время и на доработку существующей КМИС – чтобы в нее добавить возможность интеграции с новой ЭР.

Получившийся продукт является полноценным централизованным web-решением, вся клиентская часть, включая сайт для пациентов, рабочее место пользователя и администратора, клиент для инфоматов и т.д. – это «тонкие клиенты», работающие во всех наиболее популярных web-браузерах. С точки зрения операционных систем – новая ЭР не просто мультиплатформенная, а платформонезависимое решение. Применяемое общесистемное ПО не является закрытыми коммерческими продуктами. Более того, любой из компонентов можно заменить на альтернативный продукт, включая web-сервер, сервер приложений или СУБД. Это позволяет учесть такие требования времени, как импортозамещение или исключение затрат на лицензионные отчисления и зависимость от зарубежных вендоров. Вся система полностью соответствует определению «Отечественного ПО».

Еще одной важнейшей особенностью реализации проекта является тот уровень вовлеченности в процесс создания и опытного внедрения, который предоставил для нас Заказчик – МИАЦ ЯНАО. Во-первых, выработанная архитектура решения основана не только на исследованиях и взгляде разработчиков компании, но на учете мнения и постановки задачи самим Заказчиком. В нашем случае направления работ удачно совпали. Во-вторых, за время работы мы получали и получаем сейчас большой объем «обратной связи» - различные предложения по улучшению функциональности продукта, мониторинги доступности инфраструктуры и компонентов, взаимодействие с медицинскими организациями и независимыми разработчиками сторонних медицинских информационных систем и т.д. Более того, отмечу тут редкий случай – когда пожелания по разработке решения мы получали не в виде неоформленных идей, а в виде достаточно проработанных технических заданий и мотивированных поручений, что является относительно редким явлением в нашей отрасли и существенно помогает и упрощает процесс разработки и доведения до ума решения. В результате такого взаимодействия мы стали воспринимать МИАЦ скорее как высокопрофессионального и требовательного партнера, чем просто Заказчика проекта. Такой уровень доверия и взаимодействия в непростом во многих отношениях деле, который нам совместно со специалистами МИАЦ удалось обеспечить, позволяет быстро и эффективно решать возникающие оперативные проблемы и задачи.

За время опытной эксплуатации ЭР 3.0 в ЯНАО были доведены до ума интеграционный профиль, внутренняя архитектура и взаимодействие компонентов системы, протоколирование работы, функциональность. В настоящее время – новая ЭР работает в режиме реального использования, идут работы сторонних разработчиков МИС по интеграции с системой.

В результате реализации проекта мы получили следующее:

  • Накоплена необходимая компетенция, знания и опыт по созданию современных web-приложений, мы на практике поняли нюансы и некоторые сложности, которые будем учитывать в дальнейшей работе. Компания получила реальный и успешный опыт перехода в создании информационных систем с платформы IBM Notes/Domino на современный облачный подход и истинные web-приложения.

  • Мы обеспечили в новой версии ЭР большой потенциал в части масштабирования нагрузки. Новая система способна хранить и обрабатывать десятки миллионов записей с постоянно заданной высокой скоростью обработки запросов посетителей сайта записи к врачу через Интернет. В случае резкого роста нагрузки оператор системы может свободно добавлять необходимые узлы, аппаратные мощности или переконфигурировать виртуальные сервера таким образом, чтобы обеспечить необходимую производительность решения. Никакого перепрограммирования для этого не требуется –все делается привычным для облачного подхода масштабированием вычислительных мощностей: добавление серверов, памяти, процессорной мощности и т.д.

  • Система получила возможность свободной интеграции с любыми медицинскими информационными системами. Благодаря этому региональный заказчик создает равные для всех производителей МИС условия работы – т.к. интеграция с новой ЭР производится на базе открытого API и тестовой среды, в том числе – и для нашей МИС.

  • Система позволяет очень гибко менять интерфейс пользователя, т.к. внешняя «оболочка» сайта системы отделена от базового кода. Например, дизайн сайта записи на прием к врачу в ЯНАО был создан на базе тех требований к внешнему виду и графическим примитивам, которые были выработаны на уровне региона. Таким образом, теперь именно региональный заказчик определяет – как будет выглядеть данный сервис, а не разработчик решения.

  • Работающее решение независимо от геополитических рисков и нюансов взаимоотношений с отдельно взятым зарубежным вендором. При необходимости систему без переписывания исходного кода и утраты данных можно перенести на альтернативную программную платформу.


В ближайшее время Компания К-МИС официально объявит о выпуске нового программного продукта. Насколько я могу судить, существующая «Электронная регистратура» 2.6, созданная на платформе IBM Notes/Domino, будет позиционироваться нами как решение для создания сервиса записи к врачу через Интернет для отдельной медицинской организации, а новая «Электронная регистратура» 3.0 – это уже региональная система, предназначенная для реализации данного сервиса на уровне всего региона.

Интересный документ: Правительственная телеграмма от 4 марта 2014 г. № НР 18-1/10/2-1379

Согласно опубликованной на сайте Минздрава информации http://www.rosminzdrav.ru/documents/8039-pravitelstvennaya-telegramma-ot-4-marta-2014-g-nr-18-1-10-2-1379, Министерство здравоохранения просит в срок до 10 МАРТА 2014 г. заполнить и направить определенную информацию по амбулаторно-поликлиническим учреждениям.

Изучив отчет, который нужно заполнить и направить, обратил внимание:
1) В документе запрашивается информация, которая практически в полном составе есть в федеральном "Паспорте МО" и "Регистре медработников". В очередной раз вынужден задать риторический вопрос - а зачем собственно ведутся эти федеральные сервисы, оплачивается работа по их созданию и поддержанию, принуждается куча людей в регионах для их заполнения - если те запросы и отчеты, который строятся на основе данных этих регистров - все равно запрашиваются в регионах?! Ну вот никогда это толком понять не мог и не могу до сих пор. Если все эти данные запрашиваются в регионах - то значит, их нет на федеральном уровне или их невозможно получить из соответствующих федеральных систем. Если их нет на федеральном уровне - то зачем тогда созданы и требуются для работы эти учетные сервисы, зачем куча усилий по интеграции региональных фрагментов ЕГИСЗ с ними и т.д.?

2) Интересный нюанс - в документе запрашиваются такие показатели:


  • Количество автоматизированных мест, установленных на объекте (АРМ)?, ед.

из них с установленной:

  • автоматизированной системой, обеспечивающей запись на прием к врачу в электронном виде (электронная регистратура)

  • медицинской информационной системой


В комментариях к этим показателям сказано (цитата, орфографические ошибки и опечатки сохранены):
- под автоматизированным рабочим местом понимается копьютер, ноутбук или "тонкий клиент", подключенный к сети Интеренет или защищенному каналу связи, и  имеющий программное обеспечение (медицинскую информационную систему, электронную регистратуру, региональную медицинскую информационно-аналитическую систему и т.п.) для передачи медицинских документов в другие медицинские организации.
- каждая из ниже перечисленных информационных систем считается раздельно, т.е. если на одном автоматизированном рабочем месте установлена и электронная регистратура и медицинская информационная система, то такое АРМ учитывается в обеих строках


Я так понимаю, это некая попытка оценить уровень информатизации, но вот больно уж странные результаты будут получены, если собрать данные строго в соответствии с определениями и комментариями. Например, очень смущает имеющееся в комментарии ограничение - согласно которому под АРМами понимаются только компьютеры, подключенные ЛИБО к сети интернет (и тогда все равно - защищенное оно или нет), ЛИБО к защищенному каналу связи (а если ЛВС внутри МО пока не защищена - то такие АРМ засчитывать нельзя получается?). Дальше – интереснее. Исходя из формулировок получается, что АРМ нужно считать только в том случае, если они используются для передачи медицинских документов в другие МО. Другими словами - если АРМ используется только внутри МО (что, собственно говоря, бывает в подавляющем большинстве случаев, например, для автоматизации внутренних процессов в МО), то такие АРМ не интересны Минздраву и их считать не надо. Логику этих определений я пока не понял, но наверное - она какая-то все-таки есть.

О сервисе интеграции прикладных систем (ИПС)

В конце ноября на портале ЕГИСЗ были опубликованы 3 документа по новому компоненту ЕГИСЗ - подсистеме интеграции прикладных систем (далее – ИПС). В последнее время мы получили различные вопросы по этому сервису. Разбираясь с ним, изучая нормативную документацию на портале ЕГИСЗ и получив дополнительные консультации в Департаменте информатизации и связи Минздрава РФ, был составлен перечень наиболее часто задаваемых вопросов о ИПС, ответы на которые привожу в этой публикации.

Что такое «ИПС» и для чего он нужен?
Сервис интеграции прикладных систем – это общесистемный компонент ЕГИСЗ, предусмотренный еще «Концепцией создания ЕГИСЗ», утвержденной приказом Минздравсоцразвития России  №364 от 28 апреля 2011 г. (стр. 11, раздел «Сегмент централизованных общесистемных компонентов единого информационного пространства в здравоохранении»). Сервис ИПС – это единая интеграционная шина ЕГИСЗ. Появление сервиса ИПС обусловлено тем, что компоненты ЕГИСЗ создавались в разное время и разными разработчиками как отдельные (самостоятельные) продукты. Поэтому – как при интеграции федеральных компонентов ЕГИСЗ между собой, так и при интеграции региональных сегментов ЕГИСЗ с федеральными сервисами – неизбежно возникала проблема эффективности такой интеграции, особенно в будущем по мере развития ЕГИСЗ. До ИПС  ее приходилось решать путем интеграции каждой информационной системы (ИС) со всеми остальными ИС. В этом случае возникают два существенных недостатка:

  • очень трудоемко и поэтому – затратно;

  • получившаяся система становится негибкой и плохо управляемой.

В случае доработки и выпуска новой версии ИС или появления какой либо новой ИС, нужно вновь интегрировать все ИС по модели «каждый с каждым».
Выход из такой ситуации состоит в создании общей интеграционной шины. В этом случае у каждой ИС есть только одна точка подключения к ЕГИСЗ в виде «ИС - сервис ИПС».  Изменения в любой из ИС не требуют доработок других компонентов, как на федеральном, так и на региональном уровне. Кроме этого, облегчается процедура подключения новых ИС, а с учетом того, что у нас 83 региона + федеральный ЦОД, в каждом из которых не менее 5-6 различных систем, то легко представить матрицу таких подключений. ИПС представляет собой аналог системы межведомственного электронного взаимодействия (СМЭВ), используемой в электронном правительстве.
Для разработчиков регионального сегмента ЕГИСЗ этот сервис позволит оперативно обеспечить интеграцию с общесистемными и прикладными сервисами ЕГИСЗ, причем не только на уровне подключения к конкретным интеграционным веб-сервисам, но и в части идентификации, аутентификации и авторизации подключений, для чего используется сервис ЕСИАиА.
Обращаем внимание, что непосредственно ИПС сам по себе никакие данные не хранит, не принимает их и не предоставляет и не является поставщиком веб-служб. Это делают прикладные сервисы ЕГИСЗ, такие как ФЭР, ИЭМК, АХД и т.д., либо региональные сервисы. Именно их веб-сервисы публикуются в ИПС. Но для того, чтобы подключиться к веб-сервисам соответствующих прикладных компонентов, нужно вначале выполнить регистрацию в ЕСИАиА. При вызове нужного веб-сервиса в ИПС, ИПС, проверит корректность аутентификации и наличие необходимых прав, передаст соответствующий вызов прикладной системе, которая его обработает, и вернет необходимый ответ (результат). Точно также будет устроена и обратная связь: когда какому-то федеральному сервису потребуется что-то передать или вызвать веб-сервис из прикладной системы регионального уровня, она осуществит это через ИПС, в котором для корректной работы должны быть опубликованы сведения о подключении к соответствующим веб-сервисам этой прикладной региональной ИС.

Нужно ли интегрировать информационные системы регионального фрагмента ЕГИСЗ с ИПС?
ИПС – это не прикладная система, обеспечивающая какую-то определенную функциональность, а общесистемный обеспечивающий компонент. Как таковой интеграции – т.е. разработки специального программного обеспечения, для использования ИПС не требуется. Для ИПС больше подходит термин «подключение» или «публикация», подразумевающие размещение в ИПС сведений о различных ИС и их веб-сервисах для интеграции систем между собой. Для того, чтобы подключить ИС из регионального фрагмента, местный орган управления здравоохранением должен оформить специальную заявку и направить ее в адрес федерального Минздрава. Более подробно порядок подключения описан в документе «Методические материалы по подключению к Сервису ИПС», размещенный в разделе «ИПС» на портале методической поддержки ЕГИСЗ http://egisz.rosminzdrav.ru
При этом обращаем внимание, что в случае, если поставщик веб-службы требует идентификации, аутентификации и авторизации пользователя, вызвавшего веб-службу,  необходимо зарегистрировать пользователя в ФГИС ЕСИА, т.к. авторизация пользователя в данном случае осуществляется на основании данных общесистемного компонента ЕГИСЗ ЕСИАиА, который, в свою очередь функционирует на основании ФГИС ЕСИА. Регистрацию в ФГИС ЕСИА на данный момент можно осуществить по адресу http://www.gosuslugi.ru/.  Также в этом случае необходимо подключить подсистему потребитель веб-службы в соответствии с порядком, указанным в методических материалах по ЕСИАиА.

У нас выполнена интеграция с рядом федеральных сервисов. Теперь нужно будет переписывать эту интеграцию?
В настоящее время пока этого не требуется. Но очень скоро все сервисы ЕГИСЗ, будут поддерживать интеграцию не путем прямых вызовов из прикладной системы (как, например, сейчас это работает при интеграции с первой очередью ФЭР), а путем размещения соответствующих сервисов в ИПС и вызова их уже оттуда. Поэтому по мере того, как эти новые версии компонентов ЕГИСЗ будут вводиться в эксплуатацию, их интеграционные веб-сервисы будут публиковаться в ИПС и для их использования придется регистрировать ИС из регионального фрагмента в ИПС, чтобы интеграция работала корректно. Фактически, использование ИПС – это не написание какого-то отдельного специального ПО, а перенастройка уже существующих ИС в части интеграции на авторизацию и вызов веб-сервисов из ИПС Переписывание уже существующих компонентов именно из-за внедрения ИПС не требуется, кроме небольших доработок в части обеспечения электронной подписи SOAP-запросов. Но, тем не менее, заметим – что если какой-то из федеральных прикладных компонентов будет модернизирован, то вполне возможно потребуется модификация уже написанного ПО для интеграции с ним. Но требования  и конкретные изменения протоколов информационного обмена будут регламентироваться не сервисом и документацией ИПС, а документацией данного прикладного компонента.

В какие сроки нужно выполнить подключение к ИПС?
Сроки подключения к ИПС определяются требованиями к срокам начала предоставления или получения веб-службы соответствующих прикладных компонентов ЕГИСЗ, ради которых осуществляется подключение. Отдельные требования по срокам подключения к ИПС в принципе не предъявляются. В случае, если необходимости в предоставлении или получении веб-службы через ИПС нет, то подключаться к нему не нужно.

Для использования каких из существующих федеральных сервисов уже нужно использовать ИПС?
Пока не для каких.

Для использования каких из будущих федеральных сервисов нужно предусмотреть подключение к ИПС?
В данный момент – только для федеральных сервисов ИЭМК и ФЭР второй очереди.

У нас в регионе есть различные ИС. Есть региональная МИС, есть отдельные ИС для реализации прикладных задач (например, бухгалтерия и «Электронная регистратура»), есть унаследованные МИС в отдельных МО. Каким образом все эти системы должны подключаться к ИПС?
Как именно и какие именно из ИС регионального фрагмента должны подключаться к ИПС, а какие нет – решается в каждом регионе индивидуально. Идеальной выглядит ситуация, когда все прикладные информационные системы, установленные в отдельных МО или выполняющие отдельные задачи, интегрируются с единой региональной МИС, а уже эта система в свою очередь централизованно размещает собственные интеграционные веб-сервисы в ИПС и использует ИПС для подключения к федеральным сервисам. Исключением является запрос медицинского документа из ИЭМК. Он всегда персонализирован и производится от имени конкретного медицинского работника. Поэтому, если МИС установлена в МО, для получения документов из ИЭМК она должна пройти процедур интеграции.

Документация на подключения к  ИПС подразумевает разработку веб-служб. Что именно нужно делать?
Действительно, согласно документа «Методические материалы по подключению к Сервису ИПС.docx», в разделе 2 предусмотрено требование «Для осуществления информационного взаимодействия через Сервис ИПС необходимо …. разработать веб-службу, протестировать и опубликовать ее в Сервисе ИПС (в случае систем-поставщиков веб-служб) или разработать клиент к требуемой веб-службе, опубликованной в Сервисе ИПС, и провести тестирование взаимодействия с ней (в случае систем-потребителей веб-служб).». На самом деле это требование следует понимать не как разработку какого-то специального веб-сервиса для подключения к ИПС, а разработку веб-сервиса интеграции для конкретной прикладной системы (ФЭР, АХД, ИЭМК и т.д.), создав который – необходимо будет опубликовать его в ИПС для использования другими участниками. Таким образом, если речь идет о подключении к федеральному сервису – то соответствующий разработчик федерального компонента должен будет сам разработать и опубликовать свои веб-сервисы в ИПС. Для этого региональным ОУЗ и разработчикам региональных ИС ничего делать не надо. Если же речь идет о том, что нужно какие-то компоненты уже региональных ИС подключить к федеральным системам (т.е. сделать обратное действие – не регион подключить к федеральному ЦОД, а наоборот – федеральный ЦОД подключить к региональной ИС, чтобы последние могли что-то вызывать и использовать из регионального сегмента ЕГИСЗ, или передать результат обработки запроса), то в таком случае необходимо, чтобы эти веб-сервисы были разработаны соответствующими поставщиками региональных ИС и местный ОУЗ должен опубликовать информацию о них и их web-адреса в ИПС, используя процедуру, описанную в «Методических материалах по подключению к Сервису ИПС».

Можно ли как-то протестировать подключение к ИПС, не нарушая работу реальных ИС?
Да, архитектурой ИПС предусмотрены 2 площадки – тестовая и рабочая. Для тестирования и проверки взаимодействия с ИПС можно использовать тестовую среду.

В форме заявки на регистрацию ИС в тестовой версии Сервиса ИПС предусмотрено поле «Адрес стартовой страницы подсистемы». Что это такое и откуда это взять?
Данное требование попало в заявку на регистрацию ИС в ИПС ошибочно. Оно относится к подсистемам, подключающимся к ЕСИАиА.