ЭЛН. Спецификация_ЭЛН_МО_v_1_1_20180412. Назначение регламента
 Скачать 1.62 Mb.
|
 Оглавление1. Перечень изменений сервиса 4 2. Введение 5 2.1. Назначение регламента 5 2.2. Стороны обмена 5 3. Сервис информационного взаимодействия МО и ФСС РФ 6 4. Обеспечение юридической значимости 10 4.1. Используемые стандарты и алгоритмы 10 4.2. Порядок взаимодействия 10 4.3. Структура подписанного сообщения 12 4.4. Порядок формирования электронной подписи 14 5. Шифрование данных 18 5.1. Структура зашифрованного сообщения 18 6. Операция запроса нового номера ЭЛН 20 6.1. Метод getNewLNNum 20 6.1.1. Описание метода 20 6.1.2. Пример запроса 20 6.1.3. Пример ответа 21 7. Операция запроса пула новых номеров ЭЛН 23 7.1. Метод getNewLNNumRange 23 7.1.1. Описание метода 23 7.1.2. Пример запроса 23 7.1.3. Пример ответа 24 8. Операция отправки сведений ЭЛН в Фонд 26 8.1. Метод prParseFilelnlpu 26 8.1.1. Описание метода 26 8.1.2. Спецификация сообщения 26 8.1.3. Спецификация ответного сообщения (сообщения об ошибке) 34 9. Операция получения актуального ЭЛН из Фонда 36 9.1. Метод getLNData 36 9.1.1. Описание метода 36 9.1.2. Спецификация ответа 36 9.1.3. Пример запроса 36 9.1.4. Пример ответа 37 10. Операция прекращения действий с ЭЛН 39 10.1. Метод disableLn 39 10.1.1. Описание метода 39 10.1.2. Пример запроса 39 10.1.3. Пример ответа 40 11. Операция получения неиспользованных МО номеров ЭЛН 42 11.1. Метод getExistingLNNumRange 42 11.1.1. Описание метода 42 11.1.2. Пример запроса 42 11.1.3. Пример ответа 43 12. Справочники/Таблицы 45 12.1. Причины нетрудоспособности 45 12.2. Дополнительные коды 45 12.3. Типы родственных связей 45 12.4. Типы нарушений 46 12.5. Статусы нетрудоспособного 46 12.6. Состояния ЭЛН 46 12.7. Перечень возможных ошибок , при направлении запроса. 47 12.8. Код причины прекращения действия ЛН 49 Приложение 1. XSD Схема типов данных веб-сервиса 50 1. Перечень изменений сервиса Приводится перечень изменений в новой версии внешнего сервиса МО (спецификация версии 1.1) относительно предыдущей версии сервиса (спецификация версии 1.0): Метод prParseFilelnlpu со следующими изменениями структуры: Удалены следующие поля данных: SERV1_DT1 (Дата начала ухода за первым родственником); SERV1_DT2 (Дата окончания ухода за первым родственником); SERV2_DT1 (Дата начала ухода за вторым родственником); SERV2_DT2 (Дата окончания ухода за вторым родственником); Изменены параметры следующих полей данных: SURNAME (Застрахованное лицо: Фамилия). Длина, знаков = 60; NAME (Застрахованное лицо: Имя). Длина, знаков = 60; PATRONIMIC (Застрахованное лицо: Отчество). Длина, знаков = 60. Метод getLNData с изменениями, аналогичными методу prParseFilelnlpu. Добавлен новый метод getExistingLNNumRange (предоставление ранее запрошенных и не использованных номеров ЭЛН). Исключен Справочник медицинских должностей. Из справочника Код причины прекращения действия ЛН исключается код = 020 (Обнаружены расхождения с ЛН). 2. Введение 2.1. Назначение регламентаДокумент регламентирует структуру и формат данных, необходимых для обработки данных электронного листка нетрудоспособности в субъектах Российской Федерации. Документ регламентирует обмен данными в электронном виде. 2.2. Стороны обменаДанными в указанной спецификации обмениваются следующие системы: Система учета электронных листков нетрудоспособности Фонда Социального Страхования (Система учета ЭЛН ФСС) Информационные системы медицинской организации (ИС МО). 3. Сервис информационного взаимодействия МО и ФСС РФ Сервис информационного взаимодействия МО и ФСС РФ (внешний сервис МО) реализует следующие функции: запрос генерации номеров ЭЛН; получение данных ЭЛН; обновление данных ЭЛН; прекращение действия ЭЛН; запрос всех неиспользованных номеров ЭЛН по конкретному МО. Для осуществления данных функций в сервисе реализованы соответствующие методы. За генерацию номеров ЭЛН отвечают методы: getNewLNNum; getNewLNNumRange. Путем вызова данных методов ИС МО получают из системы учета ЭЛН ФСС РФ новый номер (новые номера) электронного листка нетрудоспособности для выдачи нетрудоспособному. За получение данных актуального ЭЛН из системы учета ЭЛН ФСС РФ отвечает метод: getLNData (версия 1.1). Путем вызова данного метода ИС МО получают из системы учета ЭЛН ФСС РФ данные актуальных электронных листков нетрудоспособности. За обновление данных ЭЛН отвечает метод: prParseFilelnlpu (версия 1.1). При этом передача данных осуществляется в направлении из ИС МО в систему учета ЭЛН ФСС РФ. Путем вызова данного метода ИС МО передают изменения данных ЭЛН в систему учета ЭЛН ФСС РФ в моменты открытия, продления и закрытия ЭЛН, а также при направлении на МСЭ или в другое МО. За прекращение действия ЭЛН (аннулирование) отвечает метод disableLN. Путем вызова данного метода ИС МО отправляют в систему учета ЭЛН ФСС РФ запрос на прекращения действия с электронным листком нетрудоспособности. За запрос ранее выданных и еще неиспользованных МО номеров ЭЛН отвечает новый метод getExistingLNNumRange. Путем вызова данного метода ИС МО может получить из системы ЭЛН ФСС РФ ранее выданные для МО и еще неиспользованные номера ЭЛН. Обмен сообщениями должен осуществляться в кодировке UTF-8. Ниже приведено WSDL описание сервиса (с подписанием данных): В случае непредусмотренной ошибки на сервере веб-сервис выдает ответ в стандартном поле Fault схемы http://www.w3.org/2003/05/soap-envelope/ SOAP-сообщения. Published by JAX-WS RI (http://jax-ws.java.net). RI's version is Metro/2.3.2-b608 (trunk-7979; 2015-01-21T12:50:19+0000) JAXWS-RI/2.2.11-b150120.1832 JAXWS-API/2.2.12 JAXB-RI/2.2.12-b141219.1637 JAXB-API/2.2.13-b141020.1521 svn-revision#unknown. --> Generated by JAX-WS RI (http://jax-ws.java.net). RI's version is Metro/2.3.2-b608 (trunk-7979; 2015-01-21T12:50:19+0000) JAXWS-RI/2.2.11-b150120.1832 JAXWS-API/2.2.12 JAXB-RI/2.2.12-b141219.1637 JAXB-API/2.2.13-b141020.1521 svn-revision#unknown. --> 4. Обеспечение юридической значимости 4.1. Используемые стандарты и алгоритмы Реализация механизма обеспечения юридической значимости сообщений участвующих в информационном взаимодействии МО и ФСС РФ, основано на следующих стандартах: OASIS Web Service Security: SOAP Message Security 1.1 Стандарт описывает расширения для информационного обмена посредством протокола SOAP, применение которых позволяет обеспечить целостность передаваемых сообщений. Электронно-цифровая подпись накладывается по стандарту XMLDSig, в соответствии OASIS Web Service Security: SOAP Message Security 1.1; Для каноникализации используется метод C14N; Для вычисления хэш-данных используется алгоритм ГОСТ Р 34.11-94; Для вычисления электронно-цифровой подписи используется алгоритм ГОСТ Р 34.10-2001. 4.2. Порядок взаимодействия Для обеспечения юридически значимого документооборота необходимо использовать ЭП следующих участников: Со стороны МО: ЭП медицинского работника (любой из вариантов): ЭП физического лица; ЭП юридического лица, выданная физическому лицу; ЭП Председателя ВК (любой из вариантов): ЭП физического лица; ЭП юридического лица, выданная физическому лицу; ЭП МО (любой и вариантов): ЭП юридического лица; ЭП юридического лица, выданная физическому лицу. Со стороны ФСС: ЭП ФСС (Юридическое лицо). Электронные подписи физических лиц (юридических лиц, выданных физическим лицам) аналогичны собственноручным подписям данных лиц и подтверждают, в том числе, факт формирования электронного документа конкретным участником. ЭП МО подписывается любой запрос от ИС МО к Системе учета ЭЛН, включая: - предоставление данных по ЭЛН от МО в Систему. В данном случае одна ЭП МО накладывается на совокупность данных по одному ЭЛН, при этом сообщение, отправляемое в Систему, может одновременно содержать сведения нескольких ЭЛН и в этом случае необходимо наличие нескольких подписей МО в сообщении, каждая из которых будет соответствовать данным отдельного ЭЛН; - запрос на предоставление данных актуального ЭЛН Системой; - запрос на предоставление номера или набора номеров ЭЛН. При предоставлении сведений по каждому ЭЛН от МО в Систему кроме ЭП МО так же должны быть предоставлены ЭП Врача и (при наличии) ЭП Председателя ВК. При этом ЭП МО действует на весь набор предоставляемых сведений по одному ЭЛН, а ЭП Врача и ЭП Председателя ВК действуют на выделенные блоки данных внутри сведений по одному ЭЛН. Таким образом, со сведениями по одному ЭЛН поступает одна ЭП МО и одна или более ЭП физических лиц (ЭП юридичских лиц, выданных физическим лицам). Указанные ЭП передаются в виде цепочки ЭП, каждая из которых отвечает за определенный набор сведений одного ЭЛН. За достоверность ЭП врачей и ЭП председателей ВК при передаче сведений по ЭЛН от МО в Систему отвечает сторона МО. ЭП ФСС подписывается любое ответное сообщение от Системы в результате взаимодействия с МО: - актуальное состояние ЭЛН в системе учета ЭЛН или отказ в предоставлении сведений, формируемые как ответ Системы на соответствующий запрос ЭЛН; - номер или набор номеров ЭЛН или отказ в предоставлении сведений, формируемые как ответ Системы на соответствующий запрос номера/номеров ЭЛН; - служебное сообщение, содержащее статус приема информации по ЭЛН, формируемое в ответ на предоставление данных ЭЛН от МО. На стороне Системы учета ЭЛН производится проверка всех ЭП внешних к Системе участников взаимодействия (МО, врачей и председателей ВК), предоставляющих сведения в Систему или запрашивающих сведения из Системы. На стороне МО должна производиться проверка ЭП ФСС, передаваемой вместе со сведениями, генерируемыми Системой в ответ на обращение к Системе. Проверка ЭП МО, ЭП Врача, ЭП Председателя ВК на стороне системы Состав полей ЭЛН и ЭП, им соответствующие, приведены в Процессной модели. Система осуществляет обновление данных по каждому отдельному ЭЛН в Единой БД ЭЛН только в том случае, если для всех заполненных в текущей отправке полей данного ЭЛН имеются и корректны все ЭП (предусмотренные для данных полей ЭЛН в Процессной модели), наложенные на соответствующие блоки ЭЛН и предоставленные внутри транспортных сообщений вместе с данными ЭЛН. В противном случае обновление данных по указанному ЭЛН не производится и сервисом формируется фрагмент ответного сообщения сервиса для данного ЭЛН о невозможности его обновления в виду отсутствия необходимых ЭП на данных или их некорректности. В рамках работы с данными ЭЛН посредством Внешнего сервиса МО осуществляется проверка следующего набора подписей (в зависимости от метода и состава обновляемых полей): ЭП МО; ЭП Врача; ЭП Председателя ВК. Проверка подписи Внешним сервисом МО осуществляется с использованием СКЗИ. При этом ЭП считается корректной только в следующих случаях: Она соответствует подписанному с помощью неё блоку сообщения (соответствующему блоку ЭЛН); Сертификат, посредством которого сформирована данная ЭП, действителен на настоящий момент времени и не содержится в списках отозванных сертификатов доверенных УЦ. Для ЭП МО также производится проверка, что ОГРН, указанный в сертификате данной МО, соответствует ОГРН МО, указанному в параметрах метода сервиса, а так же данная МО (по ОГРН) содержится в Реестре МО Единой БД ЭЛН. Все транспортные сообщения, приходящие на сервис, включая данные о наложенных ЭП в неизменном виде сохраняются в хранилище транспортных сообщений Единой БД ЭЛН вместе с результатами проверки ЭП для данного сообщения. Кроме того в хранилище сохраняется подписанный ЭП ФСС ответ на данное сообщение перед его отправкой получателю. Атрибуты сертификата и само значение каждой ЭП прикрепляются также к конечной реляционной сущности ЭЛН в Единой БД ЭЛН и доступны для просмотра в АРМ Сотрудника Фонда. Формирование ЭП производится на основании алгоритмов: Расчет хэш-сумм по ГОСТ Р 34.11-94 Формирования подписи по ГОСТ Р 34.10-2001. 4.3. Структура подписанного сообщения Каркас сообщения определен стандартом SOAP и представляет из себя следующий XML-документ: При этом, блок Header – содержит служебную информацию, в то время как блок Body – смысловые данные сообщения. При наложении подписи в соответствии со стандартом OASIS Web Service Security: SOAP Message Security 1.1 внутри блока Header формируется структура данных, предназначенная для передачи информации об ЭП: xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id=""> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" /> Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411" /> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" /> Блок Security, принадлежащий пространству имен http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd, содержит в себе информацию, необходимую для проверки целостности сообщения и его отправителя. В случае, если сообщение подписывается несколькими отправителями, количество тегов Security будет совпадать с количеством подписантов. Одним из параметров блока является «actor», который должен быть заполнен по следующим правилам: Для ЭП МО: «http://eln.fss.ru/actor/mo/[ОГРН_МЕДИЦИНСКОЙ_ОРГАНИЗАЦИИ] «http://eln.fss.ru/actor/mo/[ОГРН_МЕДИЦИНСКОЙ_ОРГАНИЗАЦИИ]/[Номер ЛН] – при вызове метода по обновлению данных; Для ЭП врача: «http://eln.fss.ru/actor/doc/[№ ЭЛН]_[№ подписываемого блока*]_doc Для ЭП председателя ВК: «http://eln.fss.ru/actor/doc/[№ ЭЛН]_[№ подписываемого блока*]_vk Блок Security состоит из следующих элементов: BinarySecurityToken – содержит публичный сертификат пользователя в формате X509v3. Каждый блок BinarySecurityToken имеет атрибут Id, принадлежащий пространству имен http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd, который должен быть проинициализирован уникальным значением в рамках SOAP-сообщения, по формату , аналогичному атрибуту actor; Signature – содержит информацию об электронной подписи сообщения и состоит из следующих подблоков: SignedInfo – содержит информацию о методе каноникализации, алгоритме хэширования, алгоритме генерации ЭЦП и ссылку на подписываемый блок данных; Ссылка на подписываемые данные представлена блоком Reference, Содержит атрибут URI, значение которого должно соответствовать значению атрибута Id подписываемого блока данных. Формат URI определяется для каждого типа подписи и описан в соответствующем разделе настоящей спецификации. Внутри блока Reference должны быть определены 2 элемента: DigestMethod – определяющий алгоритм вычисления хэш суммы; DigestValue – вычисленное значение хэш суммы от подписываемых данных. SignatureValue – содержит рассчитанное значение ЭП; KeyInfo – содержит ссылку на сертификат пользователя, который содержится в BinarySecurityToken и с помощью которого была рассчитана ЭП. 4.4. Порядок формирования электронной подписи В сообщение добавляются объявления префиксов пространств имен. Префиксы можно определять по мере необходимости. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ..... Проставляется атрибут wsu:Id=" " подписываемому элементу сообщения в блоке Body. В примере ниже подписывается весь блок Body. Происходит подготовка структуры для сохранения результатов. "1.0" encoding="UTF-8"?> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411" /> ....... В Формат сертификата должен соответствовать спецификации X.509 и быть представленным в формате Base64. "1.0" encoding="UTF-8"?> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="CertId">MIIDjjCCAz2..... ......... ......... ....... Добавляется ссылка на токен в раздел Значение атрибута URI элемента wsse:Reference должно соответствовать значению атрибута wsu:Id элемента wsse:BinarySecurityToken без лидирующего знака '#'. "1.0" encoding="UTF-8"?> ......... ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" /> ....... Добавляется ссылка на данные для подписи и параметры каноникализации. Значение атрибута URI элемента ds:Reference должно соответствовать значению атрибута wsu:Id у подписываемого блока данных в элементе soapenv:Body без лидирующего знака '#'. "1.0" encoding="UTF-8"?> Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411" /> ......... ....... К подписываемому элементу и его потомкам, включая атрибуты, применяется каноникализация http://www.w3.org/2001/10/xml-exc-c14n#, на основе результата рассчитывается хэш по алгоритму ГОСТ Р 34.11-94 и заносится в "1.0" encoding="UTF-8"?> ......... ........ ....... К элементу "1.0" encoding="UTF-8"?> ....... 5. Шифрование данных |