Центр поддержки
Техподдержка ЕГИСЗ
8 800 500 74 78
Написать на почту
Вход
Введите имя учетной записи для входа в систему
Введите пароль для входа в систему
Регистрация
Введите свое имя
Введите эл. почту
Введите пароль для входа в систему
Повторите ввод пароля для входа в систему
Восстановление пароля
Введите эл. почту
Вопрос Ответ
Каким образом осуществить регистрацию пользователя с ролью "пользователь с неопределённой ролью" для администратора регионального уровня? Сообщение «пользователь с таким СНИЛС уже существует» означает, что данный пользователь уже самостоятельно заходил в систему https://esiaia.rosminzdrav.ru/, создал резервный пароль и теперь у него роль в системе – «пользователь с неопределенной ролью». Вы, как администратор региона, его не видите, потому что доступ пользователей с такой ролью к Вашей ИС не предоставлен.
Вариантов решения данной проблемы два. Либо Вы сообщите в службу технической поддержки о том, что разрешаете давать доступ к Вашей ИС пользователям с такой ролью. В этом случае они должны появиться в списке доступных Вам на редактирование самостоятельно. Либо подать ЗАЯВКУ в службу технической поддержки нам на присвоение той или иной роли в сервисе ИПС для таких пользователи. Служба технической поддержки исполнит заявку, и Вы сможете их администрировать.
Для чего нужна кнопка "привязать пользователя к МО" в ИПС? Кнопка «привязать пользователя к МО» в ИПС используется в случае если пользователь-сотрудник МО вошел в Систему не по паре СНИЛС/пароль, он не будет найден в Федеральном регистре медицинского персонала автоматически. В этом случае пользователь может быть связан с учетной записью этого же пользователя в ФРМП вручную. Такая ошибка, которая возникла у Вас,  означает, что система не смогла найти этого пользователя с такими данными в ФРМП. Возможно он не медицинский работник.
Каким образом пользователи попадают в список "Пользователи, прошедшие аутентификацию на ЕСИА, но не добавленные в ЕСИАиА"? Такого списка не существует. Пользователь, прошедший регистрацию в ЕСИА на ЕСИАиА автоматически не попадает.
Он туда попадает, если его добавил администратор или пользователь может самостоятельно туда зайти, создает резервный пароль и ему будет доступен только справочник НСИ. Таким пользователям присваивается роль - «пользователь с неопределенной ролью». 
Каким образом можно добавить пользователей МО, которые не будут иметь доступа к административным функциям (методистов, регистраторов)? Указанный в документе "часто задаваемые вопросы по подключению МО к ФЭР2" способ с присвоением пользователю МО роли "Сотрудник техподдержки" не работает по причине того, что данная роль не привязана к конкретному МО, только к ИС. Предусмотрены следующие варианты ролей. Роль в ИПС «сотрудник технической поддержки» соответствует роли «сотрудник call- центра» в ФЭР 2. Такой пользователь может записывать на прием пациентов в те МО, которые были указаны при настройке прав. Роли «Сотрудник ОУЗ» и «пользователь особого типа» имеют такие же роли в ФЭР. Они предназначены для сотрудников ОУЗ и проверяющих. Для всех остальных ролей в ФЭР 2 (оператор-методист, оператор регистратуры, аналитик) надо использовать роль «администратор ИС» в ИПС. К сожалению, другого варианта нет. 
Каким образом можно добавить пользователя с ролью "Администратор ИС" для МО, использующего только веб-интерфейс ФЭР2. При создании пользователя с данной ролью пункт "Информационная система" должен быть обязательно заполнен, а в выпадающем списке ИС нет варианта для случая использования веб-интерфейса, только зарегистрированные МИС. Все верно, Вам как администратору регионального уровня доступны для администрирования региональные системы или системы уровня МО Вашего региона. Система ФЭР2 федеральная и туда Вы не можете назначить пользователей. Однако, выбрав одну из своих подсистем и поставив такому пользователю роль «администратор ИС» данный пользователь будет иметь доступ в систему ФЭР 2 автоматически. Дополнительных настроек в ИПС не потребуется. Дополнительные роли в ФЭР 2 вы смоете назначить ему сами непосредственно в системе ФЭР2. 
Что делать при поступлении заявки на присвоение роли пользователю, если пользователь не заходил самостоятельно в ЕСИАиА? Необходимо, чтобы пользователь самостоятельно первый раз зашел в ЕСИАиА после регистрации в ЕСИА. Сам создал резервный пароль. Только после этого СТП сможем присвоить данному пользователю запрашиваемую роль. Создавать пользователя, который ни разу не заходил в ЕСИАиА не рекомендуется, так как это может привести к ошибкам при входе или в базе данных.
 

 Каким образом обеспечивается защита перс. данных при обращении к сервисам ФЭР, ИЭМК через ИПС?

Где взять открытый ключ получателя (системы ИЭМК) или ИЭМК будет принимать просто зашифрованные данные без расшифровки?    
ИЭМК и ФЭР находится в защищенной сети.

Шифрование сообщения не требуется. СЭМД, передающиеся в ИЭМК подписываются сертификатом, выданным физическому лицу, пакеты данных могут сопровождаться ЭЦП.
Поясните, как подписывать сообщения при взаимодействии региональных подсистем и ЕСИАиА с помощью сертификатов?

 ​В Методических указаниях по подключению к ЕСИАиА для рег. подсистем описаны общие методические рекомендации по разработке интерфейсов для интеграции с ЕСИАиА (п. 4,3)
В частности:
Ниже представлены общие методические рекомендации по разработке интерфейсов для интеграции с ЕСИАиА.
1. Интерфейсы подсистем ЕГИСЗ для интеграции с ЕСИАиА должны быть разработаны в соответствии со стандартом обмена данными об аутентификации и авторизации между защищенными доменами SAML, версии 2.0 .
2. Запросы к ЕСИАиА от подсистемы ЕГИСЗ на идентификацию и аутентификацию пользователя должны быть подписаны с помощью закрытого ключа информационной системы с использованием следующих алгоритмов:
2.1. алгоритм c14n для каноникализации сообщения в формате XML;
2.2. алгоритмы SHA-1 и RSA для вычисления цифрового отпечатка сообщения и кода подтверждения целостности сообщения.
В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.

Более подробную информацию Вы можете найти на информационном ресурсе  разделе "Документы" - "ЕСИАиА" Там 3 документа: методические материалы, руководство пользователя и часто задаваемые вопросы. В них Вы найдете в частности и примеры запросов и ссылки на информацию по стандарту SAML 2.0

 Для регистрации информационной системы в рабочей версии Сервиса ИПС необходим квалифицированный сертификат открытого ключа. Где его взять и на кого он должен быть оформлен (МИС, на каждое МО, на регионального оператора)? Регистрация в тестовой и рабочей версиях Сервиса ИПС осуществляется с разными сертификатами: регистрация в тестовой версии возможна с самозаверенным сертификатом с методом шифрования RSA (его можно подготовить самостоятельно), в рабочей версии – только с квалифицированным сертификатом открытого ключа (т.е. выданным авторизованным удостоверяющим центром на сайте Минсвязи есть перечень УЦ апример, к НСО относятся 4 организации), соответствующим требованиям ФЗ от 06.04.2011 N 63-ФЗ "Об электронной подписи". Предоставить файл сертификата необходимо в формате *.cer.
Для каждой регистрируемой системы должен быть свой ключ, если у вас система региональная, то можете использовать ключ МЗ региона. 
Возможна ли регистрация двух ИС в рабочей версии ИПС с одним квалифицированным сертификатом ключа проверки электронной подписи? При регистрации ИС как в тестовой, так и в рабочей версиях ИПС сертификат ключа должен быть уникальным.
Как зарегистрировать ИС в промышленной версии ИПС? Оформить заявку в соответствии в формой приведенной в документе "Методические материалы по подключению к Сервису ИПС". Документ опубликован на информационном ресурсе. Заявка подается в 2 форматах - docx и pdf.  При этом в pdf должны быть проставлены дата, подпись и расшифровка подписи ответственного лица.

По требованиям ИПС все сообщения нашей МИС должны быть подписаны приватным ключом. В нашем случае приватный ключ хранится на устройстве типа eToken, сервер же нашей МИС находится на виртуальной машине сторонней организации. Т.е. доступа к USB-порту у нас нет и подключить eToken мы не можем.

Существует ли какая-то стандартная практика решения такой проблемы? Если да, то какая?

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

В системе предусмотрены следующие роли:

1. Роль «Администратор ЕСИАиА и Сервиса ИПС федерального уровня»;
2. Роль «Администратор ЕСИАиА и Сервиса ИПС регионального уровня»;
3. Роль «Администратор ИС»;
4. роль «Сотрудник ОУЗ субъекта РФ»;
5. Роль «Сотрудник технической поддержки подсистемы ЕГИСЗ»;
6. Роль «Медперсонал»;
7. Роль «Пользователь особого типа»;
8. Роль «Пользователь по умолчанию».

Более подробная информация о ролях, их возможностях и их назначении содержится на информационном ресурсе  документах:
"Методические указания по подключению к сервису ИПС",
"Часто задаваемые вопросы по подключению  к сервису ИПС".

При отправке данных в рабочую среду через ИПС возникает ошибка:
Входящее сообщение. Проверка блока security. Ошибка при проверке
подписи. -2147352567 Source: System.Xml
Description: Data at the root level is invalid. Line 1, position 1.
Судя по всему Вы используете UTF-8 c BOM, попробуйте кодировать сообщение в UTF-8 без BOM и отправить запрос заново.
Регистрация пользователей в рабочей версии ИПС? Необходимые документы от заявителя: Заявка на регистрацию пользователей в 2х форматах DOC и PDF. Файл заявки в PDF формате должен содержать  подписи ответственных лиц.

1. Регистрируем пользователей, присваивая при регистрации резервные пароли пользователям;
2. Сохраняем резервные пароли в отдельный файл, для дальнейшей отправки их заявителю.
3. После выполнения  заявки отправляем заявителю резервные пароли пользователей.