Интеграционная платформа n3 госуслуги что это
FAQ по теме интеграции с ЕСИА
Вот о ней и хотелось бы поговорить. Это ознакомительная статья, можно сказать ликбез. Для знакомства людей, которые еще не знают, что при необходимости можно использовать ЕСИА у себя в проектах и идти в ногу со временем вместе с государством. И так, что же это за зверь и как его рассматривает правительство.
Минкомсвязь России в рамках инфраструктуры электронного правительства создала и развивает Единую систему идентификации и аутентификации (ФГИС ЕСИА), цель которой — упорядочить и централизовать процессы регистрации, идентификации, аутентификации и авторизации пользователей.
1. Предоставляет информационным системам решение по достоверной идентификации пользователей (физических и юридических лиц, органов государственной власти).
Достоверность достигается за счет того, что:
Законодательство со временем корректируется, и вместе с ним расширяется перечень организаций, которым разрешено подключиться к ЕСИА.
Люди, не знакомые с ситуацией, при слове «государственная» сразу представляют себе каналы связи, которые необходимо защитить при помощи отечественных криптоалгоритмов со всеми вытекающими затратами, лицензиями и оборудованием. Но, как бы смешно это не было (или печально), главная площадка для идентификации в стране – работает с иностранной криптографией (а куда деваться).
Поэтому, если вы хотите воспользоваться услугами данной платформы, то можете размещать свои ресурсы где у годно в нашей огромной стране, в том числе и в нашей инфраструктуре Cloud4Y.
Что же может получить коммерческая организация из ЕСИА?
Перечень доступных к получению сведений зависит от:
Государственные организации могут получать из ЕСИА полный набор данных о пользователе и его организациях. Это следующие сведения:
Как подключиться?
Чтобы подключить сайт своей организации, нужно пройти несколько довольно несложных процедур.
В общих чертах для подключения к ЕСИА нужно:
Здесь нужно заметить, что с 01.01.2018 г. взаимодействие по протоколу SAML 2.0 больше не будет разрешено (только для действующих систем). Для подключения к ЕСИА необходимо будет использовать протокол OAuth 2.0 / OpenID Connect (сейчас доступны оба варианта).
Аутентификация пользователя в системе
Рекомендуемый сценарий аутентификации пользователя при интеграции по OpenID Connect 1.0 в его базовом виде происходит по следующему сценарию:
Подключаться или нет?
За операторов, в связи со вступлением в действие закона о мессенджерах данный вопрос практически решен.
Напомним, в соответствии с Федеральным законом №245 «О внесении изменений в Федеральный закон «О связи» от 29 июля 2017 года, операторы связи обязаны проверять достоверность сведений об абоненте. В законе закреплен перечень способов проверки, одним из которых является использование Единого портала государственных и муниципальных услуг или информационных систем госорганов при наличии подключения к ним у операторов через СМЭВ.
Поправки в ФЗ «О связи» вступают в силу 1 июня 2018. До этого времени операторы связи смогут протестировать работу своих систем со СМЭВ и ЕСИА. 
Становится ли чебурнет всё ближе? Официальных заявлений о планах сделать выход в Интернет возможным только через ЕСИА нами не найдено. На данный момент, по официальным данным, в ЕСИА зарегистрировано около 50 миллионов пользователей (физических лиц) и около 300 000 организаций.
Интеграция с «Госуслугами». Место СМЭВ в общей картине (часть I)
В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.
Общая схема взаимодействия через СМЭВ
Участники взаимодействия
Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.
Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).
Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.
Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.
Виды сведений
Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.
Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.
На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.
Обмен данными в промышленной среде по всем видам сведений ведётся через защищённые каналы связи. Все передаваемые данные сопровождаются электронной цифровой подписью, с помощью которой СМЭВ идентифицирует участников взаимодействия.
Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:
Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:
На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.
Обмен по универсальному виду сведений можно представить так:
На первый взгляд схема может показаться более сложной, однако она демонстрирует принципиальную разницу, которая в итоге упрощает взаимодействие между участниками по универсальному виду сведений (УВС). Специфические данные форм передаются во вложении к конверту СМЭВ, а признаки УВС, позволяющие идентифицировать вид сведений, передаются непосредственно в конверте и имеют одинаковую для любого ВС структуру:
Таким образом можно оформить предоставление практически любых услуг без необходимости проходить трудную регистрацию нового вида сведений.
Очереди сообщений и процесс взаимодействия
В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.
Взаимодействие с очередями происходит с помощью специальных запросов. Более подробно они описаны в методических рекомендациях по работе со СМЭВ. Отметим только то, что благодаря очередям становится возможным асинхронный обмен данными: потребитель может оставить заявку на получение сведений, а поставщик — разместить ответ.
Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.
На каждый запрос может поступить как успешный, так и неуспешный ответ.
Представим себя в роли поставщика сведений: по запросу мы выдаём пользователю градостроительный план земельного участка, причём в рамках нашего ведомства действуют несколько территориальных подразделений, некоторые из которых такую услугу вовсе не оказывают. Допустим, пользователь портала при формировании заявления на получение услуги указал подразделение, не оказывающее услугу. Такая ситуация может возникнуть по двум причинам:
Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.
На практике встречаются случаи, когда во время взаимодействия СМЭВ находится в режиме обслуживания, и запросы участника оборачиваются неудачей и требуют повторной отправки. Неудачу нужно зафиксировать и отправить запрос повторно.
Постановка задачи
С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.
Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.
В следующих статьях мы рассмотрим, как на стороне поставщика сведений организовать обработку заявлений по данным пользователя с использованием движка автоматизации бизнес-процессов Workflow Core.
Интеграционная платформа для портала госуслуг
Необходимость реализации большого набора государственных и муниципальных услуг в электронном виде через портал государственных (муниципальных) услуг (ПГУ) неизбежно порождает проблему организации взаимодействия данного портала с государственными и муниципальными информационными системами (ИС) с целью получения информации, необходимой для предоставления соответствующей услуги. Эта проблема вызвана большим разнообразием федеральных, региональных и муниципальных ИС, которые используют различные информационные технологии и стандарты, интерфейсы стыка, форматы баз данных и др., что значительно затрудняет реализацию взаимодействия с такими системами. Наиболее эффективным решением данной проблемы является использование так называемой среды интеграции в виде некоторой интеграционной платформы (ИП) с поддержкой специфичных для Web-сервисов стандартов и технологий.
Александр Росляков, замдиректора филиала ООО «Старт2ком», д.т.н.
Александр Гребешков, технический директор ООО «Старт2ком», к.т.н.
Михаил Самсонов, вице-президент ЗАО ГК «Старт», к.т.н.
Причины внедрения
Можно выделить две главные причины необходимости внедрения интеграционной платформы для работы ПГУ с различными ИС.
Первая состоит в том, что по мере роста количества и функционального разнообразия федеральных, региональных и муниципальных ИС технологически и организационно усложняются процессы обеспечения взаимодействия ПГУ с отдельно взятой ИС. Растут также накладные расходы на обеспечение такого взаимодействия, нередки случаи появления противоречивой информации, усиливается значимость оперативности предоставления данных и др.
Вторая причина – обеспечение гибкости и развития ПГУ при внедрении новых государственных (муниципальных) услуг.
Перечисленные выше проблемы можно было бы решить внедрением единого программного интерфейса портала со всеми существующими ИС. Но замена разнородных интерфейсов на единый не всегда оправдана, тем более что такая работа требует серьезных временных и материальных затрат в коррекции существующих региональных и муниципальных ИС. Быстро меняющиеся условия и задачи внедрения государственных и муниципальных электронных услуг диктуют необходимость немедленной работы с уже имеющимися системами, что наиболее эффективно в случае приведения этих систем к «общему знаменателю» – интеграционной платформе (ИП).
Основное назначение ИП – согласование и гармонизация данных нескольких информационных систем (приложений) в определенной сфере деятельности (образование, здравоохранение, ЖКХ и др.) в соответствии с утвержденным регламентом работы ПГУ при предоставлении государственных (муниципальных) услуг. Интеграционная платформа оснащается специальными программными адаптерами для сбора в единой форме информации от различных ИС, относящихся к определенной сфере деятельности.
Функции ИП
Платформа интеграции не является местом хранения данных, она лишь реализует собой сервер федерализации данных, позволяющий организовать интеграционные процессы для ИС при работе с ПГУ. Интеграционная платформа выполняет следующие функции:
Пользователь ПГУ через свой личный Web-кабинет в Интернете подает заявку на оказание государственной (муниципальной) услуги (ГУ) из списка предоставляемых ГУ посредством соответствующих Web-форм. ПГУ через систему межведомственного электронного взаимодействия (СМЭВ) передает запрос в ИП. Интеграционная платформа как сервис SaaS располагается на Национальной платформе распределенной обработки данных (НПРОД) (рис. 1).
Рис.1. Место интеграционной платформы при предоставлении государственных (муниципальных) услуг через ПГУ
На рис. 2 изображен пример диаграммы последовательности обработки запроса из ПГУ при предоставлении государственной (муниципальной) слуги с использованием данных из двух информационных систем – ИС-1 и ИС-N под управлением платформы интеграции.
Рис.2. Схема обработки запроса из ПГУ с использованием ИП
При получении через СМЭВ запроса из ПГУ на реализацию определенной государственной (муниципальной) услуги, интеграционная платформа определяет перечень ИС, в которых находится необходимая информация. В рассматриваемом на рис. 2 примере запрашиваемая для услуги информация располагается в двух системах: ИС-1 и ИС-N. ИП отправляет запрос данных через адаптер 1 в ИС-1 и получает от нее результат обработки. Аналогично осуществляется запрос необходимой информации из ИС-N. Получив все необходимые для предоставления государственной (муниципальной) слуги данные из ИС-1 и ИС-N, интеграционная платформа возвращает результат обработки в ПГУ через СМЭВ.
Преимущества использования платформы интеграции данных
Прозрачность информации для ПГУ
Благодаря интеграции данных ПГУ имеет дело с единым и единообразным интерфейсом. Прозрачность информации означает, что приложению (государственной или муниципальной услуге на базе ПГУ), потребляющему данную информацию, нет необходимости иметь представление о том, где хранятся данные. Благодаря прозрачности обработки запроса ПГУ может также не знать, какой язык или интерфейс программирования поддерживается исходной базой данных. Приложению ПГУ также необязательно знать физические условия хранения данных или то, какие используются сетевые протоколы (сетевая прозрачность).
Единообразие взаимодействия ПГУ с ИС
Приложение (государственная или муниципальная услуга на базе ПГУ), являющееся потребителем сервиса ИП, может взаимодействовать с единым виртуальным источником данных. В противном случае приложение ПГУ должно взаимодействовать с несколькими источниками данных индивидуально через различные интерфейсы и с использованием разных протоколов.
Сокращение затрат на разработку и обслуживание государственных и муниципальных услуг
Многие государственные и муниципальные услуги, реализуемые через ПГУ, могут потенциально иметь одинаковые или очень сходные запросы на информацию из определенной сферы деятельности. Согласно принципам предлагаемой платформы, интегрированное решение разрабатывается один раз и после этого используется и обслуживается централизованно в НПРОД. Таким образом, формируется единая точка входа и изменения данных для ПГУ. Такой подход сокращает расходы на разработку и поддержку программных продуктов. Аналогично однажды разработанный адаптер для интеграции конкретной ИС в определенной сфере деятельности может быть многократно использован для интеграции с множеством однотипных ИС.
Есть ли альтернатива использованию ИП?
Возможно, конечно, встраивание интеграционных механизмов в интегрируемые ИС, то есть коррекция существующих информационных систем таким образом, чтобы они «умели» взаимодействовать с ПГУ в правильном порядке, который отражает процесс предоставления государственных (муниципальных) услуг. Этот затратный и сложный путь приводит всю интегрированную систему ПГУ в тупик, потому что при добавлении новых приложений, внесении изменений в уже существующие услуги или хотя бы в порядок их взаимодействия, то есть в процесс предоставления государственных (муниципальных) услуг, необходимо внести изменения во многие приложения всего комплекса. Ведь все ИС «жестко завязаны», и желание что-то изменить в одном месте порождает множество попутных изменений в различных системах.
По оценкам зарубежных экспертов, на каждый доллар, вложенный в создание интеграционной платформы, приходится от 8 до 14 долларов, вложенных в разработку информационной системы на ее основе.
В настоящее время реализован опытный образец сегмента ИП, обеспечивающий реализацию двух видов муниципальных услуг в сфере ЖКХ: информирование о начислениях за жилищно-коммунальные услуги и информирование об объемах потребления энергоресурсов. Прикладное программное обеспечение ИП реализовано на основе свободно распространяемого программного обеспечения и языка программирования Java.
По оценкам зарубежных экспертов, на каждый доллар, вложенный в создание интеграционной платформы, приходится от 8 до 14 долларов, вложенных в разработку информационной системы на ее основе. Иными словами, практический опыт подсказывает, что именно возможность унифицированного взаимодействия представляет основную практическую ценность интеграционной платформы, поскольку экономически целесообразнее (дешевле и быстрее) реализовать единый прикладной программный интерфейс к нескольким информационным системам, чем использовать множество специфических интерфейсов взаимодействия. В результате создание ИП позволит не только сэкономить время и финансы, но и значительно повысить удобство администрирования портала государственных (муниципальных) услуг.
Здравоохранение
Интеграционная платформа «N3.Здравоохранение» предназначена для создания государственных информационных систем в сфере здравоохранения (ГИСЗ) субъектов РФ в рамках федерального проекта «Создание единого цифрового контура в здравоохранении на основе единой государственной информационной системы в сфере здравоохранения (ЕГИСЗ)».
Интеграции
50+ интегрированных МИС: Ариадна, САМСОН, Инфоклиника, Авиценна, Вита-Софт, Виста-Мед, Web-поликлиника, 1С-Медицина, Электронная медицина, Евромед, Аура, Электрон, Dental4Windows, Глобус-Медикус, PSS Labs, КМИВЦ, Витакор, qMS, Медиалог, Барс, КМИС, РТ Лабс, МИС Байкал, а также с лабораторными ИС от Акросс и Ситилаб, ЛИС Алтэй, с системой обработки диагностических изображений Agfa IMPAX и телекоммуникационной платформой Asterisk.
Решаемые задачи
Результаты внедрения
Выполнение требований МЗ РФ в части подсистем ГИСЗ субъектов РФ в соответствии с приказом МЗ РФ от 24.12.2018 №911н.
Эффективное взаимодействие информационных систем в сфере здравоохранения для медорганизаций всех форм собственности.
Оптимизация региональных процессов цифрового здравоохранения: записи на прием к врачу, управления потоками пациентов, создания интегрированной электронной медицинской карты, обмена данными лабораторных и диагностических исследований, управления нормативно-справочной информацией и других.
Повышение качества принимаемых управленческих решений за счёт возможности формирования аналитических отчетов на основе данных из всех интегрированных систем с детализацией до любого уровня: медорганизации, пациента, случая обслуживания.