Приказ ФФОМС от 07.04.2011 N 79 (ред. от 05.03.2020) "Об утверждении Общих принципов построения и функционирования информационных систем и порядка информационного взаимодействия в сфере обязательного медицинского страхования"

ФЕДЕРАЛЬНЫЙ ФОНД ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ

ПРИКАЗ

от 7 апреля 2011 г. N 79

ОБ УТВЕРЖДЕНИИ ОБЩИХ ПРИНЦИПОВ

ПОСТРОЕНИЯ И ФУНКЦИОНИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

И ПОРЯДКА ИНФОРМАЦИОННОГО ВЗАИМОДЕЙСТВИЯ В СФЕРЕ

ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ"

В соответствии с частью 8 статьи 33 Федерального закона от 29 ноября 2010 года N 326-ФЗ "Об обязательном медицинском страховании в Российской Федерации" приказываю:

Утвердить Общие принципы построения и функционирования информационных систем и порядок информационного взаимодействия в сфере обязательного медицинского страхования.

Председатель

А.В.ЮРИН

Утверждено

приказом ФОМС

от 7 апреля 2011 г. N 79

ОБЩИЕ ПРИНЦИПЫ

ПОСТРОЕНИЯ И ФУНКЦИОНИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

И ПОРЯДОК ИНФОРМАЦИОННОГО ВЗАИМОДЕЙСТВИЯ

В СФЕРЕ ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ

1 Цель документа

Целью настоящего документа является установление единых требований и правил информационного взаимодействия, применяемых участниками и субъектами обязательного медицинского страхования на территории Российской Федерации.

2 Сокращения и определения

Таблица 1 Перечень сокращений, используемых в документе

3 Область применения и порядок вступления в силу

Сформулированные в рамках настоящего документа требования являются обязательными для всех информационных систем участников и субъектов ОМС, осуществляющих информационный обмен.

Особенности сроков перехода на применение положений некоторых разделов настоящего документа приведены в таблице 2.

Таблица 2 Сроки перехода на применение положений отдельных разделов настоящего документа

--------------------------------

<1> Классификатор тем обращений граждан вводится в действие с 01.07.2019.

4 Общие требования к построению

и функционированию информационных систем в сфере

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

Таблица 3 Структура ИС ОМС

--------------------------------

<1> Здесь и далее по тексту указывается номер пункта (подпункта) документа, в котором описаны требования к подсистеме или к функциям подсистемы.

4.1 Перечень НСИ и реестров в сфере ОМС

Таблица 4 Перечень НСИ и реестров в сфере ОМС

--------------------------------

<1> Указывается для объектов НСИ, включенных в федеральный пакет НСИ.

<2> Контроля объемов, сроков, качества и условий предоставления медицинской помощи по ОМС.

<3> Код (номер) пункта выдачи полисов формируется для данной СМО внутри региона.

4.2 Информационное взаимодействие при ведении НСИ и реестров в сфере ОМС

Участники информационного взаимодействия:

- Федеральный фонд обязательного медицинского страхования;

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

- страховые медицинские организации;

- медицинские организации.

Схема информационного взаимодействия при ведении НСИ и реестров в сфере ОМС представлена на рисунке 1.

Территориальные фонды обязательного медицинского страхования осуществляют ведение своих сегментов единого реестра МО и единого реестра СМО (F002 и F003) в Подсистеме "Реестры ОМС"; сегментов справочника ТФОМС (F001), реестра пунктов выдачи полисов (F013), перечня технологических правил реализации ФЛК регионального уровня в ИС ведения персонифицированного учета сведений об оказанной медицинской помощи (Q022), перечня проверок автоматизированной поддержки МЭК регионального уровня в ИС ведения персонифицированного учета сведений об оказанной медицинской помощи (Q023) - в Подсистеме НСИ Государственной информационной системы обязательного медицинского страхования; сегмента единого реестра экспертов качества медицинской помощи - с применением программного обеспечения ТФОМС, обеспечивающего ведение территориального реестра экспертов качества медицинской помощи в соответствии с требованиями нормативных правовых документов.

Территориальные фонды обязательного медицинского страхования размещают на своем официальном сайте в сети Интернет свои сегменты единого реестра медицинских организаций, страховых медицинских организаций, пунктов выдачи полисов и обеспечивают возможность их выгрузки в форматах XML (кодовая страница Windows-1251).

Рисунок 1 Информационное взаимодействие при ведении НСИ

и реестров в сфере ОМС

Порядок предоставления файлов справочника территориальных фондов обязательного медицинского страхования, реестров медицинских организаций, страховых медицинских организаций, описан в подпункте 4.2.1 настоящего документа.

Федеральный фонд обязательного медицинского страхования размещает на своем корпоративном Интернет сайте https://project.ffoms.ru (раздел Справочники и реестры) федеральный пакет НСИ, а также справочник территориальных фондов обязательного медицинского страхования, реестры медицинских организаций, страховых медицинских организаций.

Файлы для формирования и ведения единого реестра экспертов качества медицинской помощи направляются в ФОМС по защищенному каналу связи VipNet.

Все участники информационного взаимодействия обеспечивают получение и использование в своих информационных системах нормативно-справочной информации, включенной в федеральный пакет НСИ, а также справочника территориальных фондов обязательного медицинского страхования, реестров медицинских организаций, страховых медицинских организаций.

Все участники информационного взаимодействия обязаны обеспечить исполнение законодательства Российской Федерации по вопросам защиты информации, в отношении которой установлено требование об обеспечении ее конфиденциальности.

4.2.1 Порядок предоставления файлов

Структура и состав показателей справочника территориальных фондов обязательного медицинского страхования, реестров медицинских организаций, страховых медицинских организаций, экспертов качества медицинской помощи и реестра пунктов выдачи полисов описаны в Приложении А (F001 - F004, F013).

При изменении сведений в справочнике территориальных фондов ответственный специалист ТФОМС в течение 2 рабочих дней с даты изменения сведений актуализирует их в Подсистеме НСИ; при изменении сведений реестров МО, СМО ответственный специалист ТФОМС в соответствии с пунктами 91, 111 Правил ОМС в течение 5 рабочих дней со дня представления МО и СМО в ТФОМС документов, подтверждающих изменения сведений, актуализирует сведения в Подсистеме "Реестры ОМС".

Актуализация справочника территориальных фондов обязательного медицинского страхования, реестров медицинских организаций, страховых медицинских организаций осуществляется ФОМС на официальном Интернет-портале ФОМС в течение 2 рабочих дней со дня представления ТФОМС информации об изменениях.

4.2.2 Правила формирования федерального пакета НСИ

При формировании федерального пакета НСИ файлы пакета должны быть упакованы в архив формата ZIP. Имя архивного файла должно быть сформировано по следующему правилу:

NXYYMMVVV.ZIP, где:

- N - обязательный буквенный символ латинского алфавита;

- X - символ, определяющий тип файла, который может принимать значения:

- "i" - пакет с изменениями, содержащий только те справочники, по которым произошли изменения;

- "p" - Полный пакет, содержащий всю НСИ, за исключением справочника ТФОМС и Единых реестров (пункты 26 - 29 Таблицы 4 настоящего документа);

- YY - две последние цифры года формирования пакета

- MM - номер месяца формирования пакета (01 - январь, 02 - февраль и т.д. до 12 - декабрь)

- VVV - номер версии пакета: 001..999.

- ZIP - стандартное расширение имени файла, соответствующего типу архивного файла.

Федеральный пакет НСИ формируется в соответствии со сведениями, приведенными в Таблице 4 настоящего документа, и публикуется ФОМС в Подсистеме НСИ Государственной информационной системы обязательного медицинского страхования (http://nsi.ffoms.ru).

Внесение изменений в состав НСИ, входящей в федеральный пакет, происходит по письменной заявке участника информационного взаимодействия.

Внесение изменений в перечень технологических правил реализации ФЛК в ИС ведения персонифицированного учета сведений об оказанной медицинской помощи (Q015), перечень проверок автоматизированной поддержки МЭК в ИС ведения персонифицированного учета сведений об оказанной медицинской помощи (Q016), перечень категорий проверок ФЛК и МЭК (Q017), описание правил заполнения элементов файлов информационного обмена при ведении персонифицированного учета сведений об оказанной медицинской помощи (Q018) и их публикация осуществляется ФОМС не позже, чем за 1 месяц до вступления изменений в действие, если иное не предусмотрено нормативными правовыми актами.

4.3 Требования к региональной информационной системе обязательного медицинского страхования

Таблица 5 Структура региональной информационной системы обязательного медицинского страхования

Таблица 6 Перечень функций, выполняемых региональной информационной системой обязательного медицинского страхования, к которым предъявляются требования в настоящем документе

Рисунок 2 Общая схема информационного взаимодействия

в сфере ОМС

4.3.1 Общие требования к информационной системе территориального фонда обязательного медицинского страхования

Таблица 7 Перечень обязательных подсистем информационной системы территориального фонда обязательного медицинского страхования

4.3.1.1 Требования к подсистеме ведения Регионального сегмента Единого регистра застрахованных лиц

Таблица 8 Перечень сведений о застрахованных лицах в РС ЕРЗ

--------------------------------

<1> Контрольный разряд номера полиса обязательного медицинского страхования, вычисляется арифметически в соответствии с методикой расчета, описанной в международном стандарте ISO/HL7 27931:2009 (алгоритм Mod10).

Таблица 9 Перечень функций ТФОМС при ведении РС ЕРЗ

4.3.1.2 Требования к подсистеме ведения персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования

В подсистеме ведения персонифицированного учета медицинской помощи, оказанной в сфере ОМС, должны осуществляться сбор, обработка, передача и хранение сведений о медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования, перечень которых представлен в таблице 10. Информационное взаимодействие при ведении персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования, представлено на рисунке 3.

Рисунок 3 Информационное взаимодействие при ведении

персонифицированного учета медицинской помощи, оказанной

застрахованным лицам в сфере ОМС

Таблица 10 Перечень сведений о медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования

Таблица 11 Перечень функций подсистемы ведения персонифицированного учета медицинской помощи, оказанной в сфере обязательного медицинского страхования

Таблица 12 Перечень проверок автоматизированной поддержки МЭК, МЭЭ и ЭКМП

4.3.1.3 Требования к подсистеме информирования граждан (официальному сайту территориального фонда обязательного медицинского страхования в сети Интернет)

4.3.1.3.1 Общие требования

1) Отсутствие взимания платы за доступ к информации сайта;

2) Отсутствие необходимости в использовании специального программного обеспечения, кроме веб-обозревателя (браузера);

3) Круглосуточный доступ к информации;

4) Уведомление о проведении плановых технических работ, в ходе которых доступ пользователей к информации, размещенной на официальном сайте, будет невозможен, не менее чем за сутки до начала работ;

5) Обеспечение восстановления работоспособности официального сайта не более чем через 24 часа с момента возникновения технических неполадок, неполадок программного обеспечения или иных проблем, влекущих невозможность доступа пользователей к официальному сайту или к его отдельным страницам;

6) Размещение информации на сайте на русском языке. Возможно дублирование информации на других языках. Не допускается использование сокращений, кроме общепринятых;

7) Интерфейс сайта должен обладать целостностью, разделы сайта преимущественно не должны различаться по стилю и способу навигации;

8) Текст должен быть разбит на разделы и абзацы, важная информация должна выделяться;

9) Заголовки и подписи на страницах должны описывать содержание (назначение) данной страницы, наименование текущего раздела и отображаемого документа;

10) Наименование страницы, описывающее ее содержание (назначение), должно отображаться в заголовке окна веб-обозревателя;

11) Информация на официальном сайте размещается в виде текста в гипертекстовом формате - формате HTML. Для обеспечения высокой скорости скачивания документов, размещенных на сайте, рекомендуется применение архиватора ZIP;

12) Недопустимо наличие незаполненных разделов (подразделов) сайта без указания причин отсутствия их заполнения;

13) Сайт должен работать под нагрузкой, определяемой числом обращений к сайту пользователями информации, двукратно превышающей максимальное суточное число обращений к сайту пользователей информацией, зарегистрированных за последние 6 месяцев эксплуатации официального сайта; вновь созданный либо функционирующий менее 6 месяцев официальный сайта - под нагрузкой не менее 10 000 обращений к сайту в месяц.

4.3.1.3.2 Требования к составу информации

Перечень информации, размещаемой на официальном сайте ТФОМС, представлен в таблице 13. Детализированные требования к составу информации представлены в таблице 14.

Таблица 13 Состав информации официального сайта ТФОМС

Таблица 14 Детализированный состав информации официального сайта ТФОМС

4.3.2 Общие требования к информационной системе страховой медицинской организации

Таблица 15 Структура информационной системы страховой медицинской организации

4.3.2.1 Требования к подсистеме персонифицированного учета сведений о застрахованных лицах

Таблица 16 Перечень функций, реализуемых подсистемой ведения персонифицированного учета сведений о застрахованных лицах страховой медицинской организации

4.3.2.2 Требования к подсистеме персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования

Таблица 17 Перечень функций подсистемы персонифицированного учета медицинской помощи, оказанной в сфере обязательного медицинского страхования, в страховой медицинской организации

4.3.2.3 Требования к подсистеме информирования граждан (официальному сайту страховой медицинской организации в сети Интернет)

4.3.2.3.1 Общие требования

1) Отсутствие взимания платы за доступ к информации сайта;

2) Отсутствие необходимости в использовании специального программного обеспечения, кроме веб-обозревателя (браузера);

3) Круглосуточный доступ к информации;

4) Уведомление о проведении плановых технических работ, в ходе которых доступ пользователей к информации, размещенной на официальном сайте, будет невозможен, не менее чем за сутки до начала работ;

5) Работоспособность официального сайта должна быть восстановлена не более чем через 24 часа с момента возникновения технических неполадок, неполадок программного обеспечения или иных проблем, влекущих невозможность доступа пользователей к официальному сайту или к его отдельным страницам;

6) Размещение информации на сайте осуществляется на русском языке. Не допускается использование сокращений, кроме общепринятых;

7) Интерфейс сайта должен обладать целостностью, разделы сайта не должны различаться по стилю и способу навигации;

8) Текст должен быть разбит на разделы и абзацы, важная информация должна выделяться возможными способами;

9) Заголовки и подписи на страницах должны описывать содержание (назначение) данной страницы, наименование текущего раздела и отображаемого документа;

10) Наименование страницы, описывающее ее содержание (назначение), должно отображаться в заголовке окна веб-обозревателя;

11) Информация на официальном сайте размещается в виде текста в гипертекстовом формате - формате HTML. Для обеспечения высокой скорости скачивания документов, размещенных на сайте, рекомендуется применение архиватора ZIP;

12) Недопустимо наличие незаполненных разделов (подразделов) сайта;

13) Обязательно наличие на сайте системы навигации;

14) Сайт должен работать под нагрузкой, определяемой числом обращений к сайту пользователями информации, двукратно превышающей максимальное суточное число обращений к сайту пользователей информацией, зарегистрированных за последние 6 месяцев эксплуатации официального сайта; вновь созданный либо функционирующий менее 6 месяцев официальный сайта - под нагрузкой не менее 10 000 обращений к сайту в месяц.

4.3.2.3.2 Требования к составу информации

Перечень информации, размещаемой на официальном сайте СМО, представлен в таблице 18. Детализированные требования к составу информации представлены в таблице 19.

Таблица 18 Состав информации официального сайта СМО

Таблица 19 Детализированный состав информации официального сайта СМО

4.3.3 Общие требования к информационной системе медицинской организации

Таблица 20 Перечень подсистем информационной системы медицинской организации

4.3.3.1 Требования к подсистеме персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования

Таблица 21 Перечень функций подсистемы персонифицированного учета медицинской помощи, оказанной в сфере обязательного медицинского страхования, в медицинской организации

5 Порядок информационного взаимодействия в сфере

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

5.1 Регламент информационного взаимодействия при ведении Единого регистра застрахованных лиц

Рисунок 4 Информационное взаимодействие при ведении ЕРЗ

Идентификатором в сфере обязательного медицинского страхования является ЕНП. Правила формирования ЕНП утверждены и контролируются ФОМС. Первые два фасета номера соответствуют территории, рассчитавшей ЕНП. ЕНП сохраняется неизменным в течение всей жизни застрахованного лица и может быть изменен только в случае несоответствия установленному правилу его вычисления. ЕНП застрахованного лица определяется в результате запроса в ЦС ЕРЗ. В случае объединения данных с разными ЕНП определяется главный ЕНП, используемый в дальнейшем.

5.1.1 Информационное взаимодействие между Региональным сегментом и Центральным сегментом ИС ЕРЗ

Таблица 22 Перечень сведений, передаваемых при ведении ЕРЗ между Региональным и Центральным сегментами ИС ЕРЗ

Передача сведений осуществляется по определенному регламенту.

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

5.1.2 Информационное взаимодействие между ТФОМС и СМО при ведении Регионального сегмента Единого регистра застрахованных лиц

Обмен информацией между СМО и ТФОМС может быть организован одним из следующих способов:

1) Пакетный режим. СМО и ТФОМС осуществляют обмен данными методом передачи, приемки и обработки информационных посылок, содержащих файлы с изменениями и файлы подтверждения и/или отклонения изменений. Состав, структура, порядок расположения, размерность, именование и правила заполнения полей файлов информационных посылок определены в Приложении Г к настоящему документу и должны поддерживаться программным обеспечением всех участников информационного обмена. Внесение изменений, корректировок и дополнений в формат файла информационного обмена участниками информационного обмена не допускается.

2) Информационный обмен, осуществляемый с применением электронных сервисов ТФОМС. СМО осуществляет функции ведения РС ЕРЗ в части собственного сегмента непосредственно в базе данных ТФОМС посредством использования электронных сервисов.

Обмен по второму способу является предпочтительным.

5.1.2.1 Информационное взаимодействие в пакетном режиме

Страховая медицинская организация передает файлы с изменениями в ТФОМС по мере необходимости, но не реже 1 раза в день при наличии изменений в сведениях о застрахованных лицах, в соответствии с договором о финансовом обеспечении обязательного медицинского страхования. ТФОМС обеспечивает круглосуточный режим приема и обработки файлов с изменениями, поступивших от страховых медицинских организаций.

Медицинская организация передает в страховые медицинские организации и ТФОМС файлы с изменениями сведений о медицинской организации и медицинском работнике, выбранных застрахованным лицом в соответствии с законодательством Российской Федерации для получения первичной медико-санитарной помощи, по мере необходимости, но не реже 1 раза в день при наличии изменений в указанных сведениях о застрахованных лицах.

Файл с изменениями (в файл с изменениями включаются все вновь введенные и измененные с момента последней отправки сведения о застрахованных лицах) представляется в формате XML (кодовая страница Windows-1251).

Структура файла с изменениями и правила его заполнения описаны в Приложении Г Настоящего документа.

В ТФОМС формируются файлы подтверждения и/или отклонения изменений (содержит информацию по всем операциям, проведенным с предоставленной информацией о застрахованном лице) в формате XML (кодовая страница Windows-1251). Формат файла должен соответствовать формату, приведенному в Приложении Г.

Файлы от ТФОМС с извещениями СМО о прекращении страхования (снятии с учета застрахованных лиц), файлы корректировки данных (восстановление на учете застрахованных лиц) должны направляться в СМО в день внесения изменений в Региональный сегмент ЕРЗ. Файлы от ТФОМС с извещениями СМО на основании сведений о государственной регистрации заключения или расторжения брака, установления отцовства, перемены имени, содержащихся в ЕГР ЗАГС, должны направляться в СМО не реже 1 раза в неделю при наличии изменений сведений о застрахованном лице.

При реализации информационного обмена с применением пакетного режима обмена данными ТФОМС формирует и контролирует соблюдение СМО технических требований по подключению к соответствующему сервису системы ведения РС ЕРЗ.

Таблица 23 Перечень сведений, передаваемых между ТФОМС и СМО при пакетном режиме обмена информацией

5.1.2.2 Информационное взаимодействие СМО с Региональным сегментом Единого регистра застрахованных граждан с использованием электронных сервисов ТФОМС

При реализации информационного обмена с применением электронных сервисов ТФОМС обеспечивает:

- круглосуточную доступность электронных сервисов ТФОМС, обеспечивающих информационное взаимодействие с РС ЕРЗ;

- формирование правил и порядка, а также контроль использования СМО электронных сервисов ТФОМС, обеспечивающих информационное взаимодействие с РС ЕРЗ;

- формирование и контроль соблюдения технических требований по подключению СМО к электронным сервисам ТФОМС, обеспечивающим информационное взаимодействие с РС ЕРЗ.

Применение электронных сервисов ТФОМС, обеспечивающих информационное взаимодействие с Региональным сегментом ЕРЗ, должно обеспечить доступ СМО к следующему функционалу:

- ввод заявлений на выбор (замену) СМО, о сдаче (утрате) полиса ОМС и переоформление (выдачу дубликата) полиса ОМС;

- просмотр истории постановки застрахованных лиц на учет и снятия с учета на данной территории страхования;

- поиск застрахованных лиц по демографическим данным;

- сведения о заявлениях граждан и их представителей на выбор (замену) СМО, о сдаче (утрате) полиса ОМС и переоформлении (выдаче дубликата) полисов ОМС, включая результаты рассмотрения заявлений;

- сведения о выпущенных, полученных, выданных, аннулированных и списанных документах, подтверждающих факт страхования (ДПФС).

Участники информационного обмена обеспечивают защиту передаваемой информации в соответствии с действующим законодательством. Информационное взаимодействие с применением электронных сервисов ТФОМС должно обеспечивать:

- предоставление доступа к защищенным ресурсам только пользователям, прошедшим процедуру идентификации и проверку подлинности;

- разграничение прав доступа к защищенным ресурсам на основе функциональных и структурных ролей пользователей;

- защиту идентификационной информации пользователей;

- регистрацию входа/выхода пользователей с фиксированием даты, времени и результата события;

- регистрацию фактов получения доступа к защищенным ресурсам и информации с фиксированием даты, времени и результата события.

5.2 Регламент информационного взаимодействия при ведении персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования

В информационном обмене при осуществлении персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования, в указанном порядке осуществляются взаимодействия, перечисленные в таблице 24.

Таблица 24 Информационное взаимодействие при ведении персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования

5.2.1 Действия участников

Организация-получатель производит форматно-логический контроль целостности данных в файлах, представленных в пакете информационного обмена. При наличии ошибок организация-отправитель устраняет их и повторяет процедуру информационного обмена.

5.2.2 Способ передачи и приема объектов

Информационный обмен осуществляется в электронном виде по выделенным или открытым каналам связи, включая сеть "Интернет", с использованием средств криптографической защиты информации и электронной подписи в соответствии с требованиями законодательства Российской Федерации в сфере защиты информации и персональных данных гражданина.

В случае отсутствия возможности обеспечения юридически значимого документооборота, передаваемые документы должны подтверждаться на бумажных носителях.

В случае невозможности осуществления защищенного телекоммуникационного взаимодействия субъектов информационного обмена, передача-приемка данных производится в явочном порядке.

5.2.3 Ответственный по процессу

Организация-отправитель отвечает за подготовку и передачу данных.

Организация-получатель отвечает за готовность программно-технологической среды, организацию приема данных, прием и контроль полученных данных по установленным правилам.

5.3 Регламент информационного взаимодействия при ведении персонифицированного учета медицинской помощи, оказанной застрахованным лицам в сфере обязательного медицинского страхования за пределами субъекта Российской Федерации, на территории которого выдан полис обязательного медицинского страхования

Информационный обмен при осуществлении расчетов за медицинскую помощь, оказанную застрахованным лицам при возникновении страхового случая за пределами того субъекта Российской Федерации, на территории которого лицо состоит на учете (далее - межтерриториальные расчеты), осуществляют территориальные фонды ОМС в соответствии с Правилами ОМС.

Информационный обмен осуществляется в электронном виде по выделенным или открытым каналам связи, включая сеть "Интернет", с использованием средств криптографической защиты информации и электронной подписи в соответствии с требованиями законодательства Российской Федерации в сфере защиты информации и персональных данных гражданина.

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

6 Протоколы информационного обмена

6.1 Протокол обмена ISO 27931:2009

6.1.1 Общие сведения о протоколе обмена ISO 27931:2009

Информационное взаимодействие при персонифицированном учете застрахованных лиц и выпуске полисов ОМС осуществляется по протоколу ISO 27931:2009, адаптированному для использования в сфере ОМС РФ. В качестве версии для адаптации выбрана версия 2.6 исходного протокола ISO 27931:2009.

6.1.1.1 Концептуальный подход

6.1.1.1.1 События и прямые сообщения

События, происходящие в сфере ОМС и требующие обмена сообщениями, называются событиями, требующими реакции, или просто событиями. Когда передача информации инициируется прикладной системой в связи с событием, требующим реакции, то соответствующая транзакция называется прямой транзакцией или описательной транзакцией, а сообщение, передаваемое при этой транзакции - прямым сообщением или описательным сообщением.

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

6.1.1.1.2 Подтверждения

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

В описываемой реализации стандарта ISO 27931 предусмотрен расширенный режим подтверждения, при котором различается два вида подтверждения: подтверждение приема и подтверждение прикладной обработки сообщения.

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

6.1.1.1.3 Запросы

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

6.1.1.1.4 Повелительные сообщения

Повелительное сообщение представляет собой команду, которую должна выполнить прикладная система, которой адресовано сообщение. В настоящем документе повелительные сообщения не рассматриваются.

6.1.1.1.5 Общая схема обмена данными

Во всех случаях согласно стандарту ИСО 27931 передача данных состоит в простом обмене сообщениями между парой приложений. Схема такого обмена в режиме расширенного подтверждения показана на рисунке 5.

┌──────────────────┐                                   ┌──────────────────┐
│                  │                                   │                  │
│                  │      ОПИСАТЕЛЬНАЯ транзакция      │                  │
│                  │                                   │                  │
│                  │          Описание данных          │                  │
│                  ├──────────────────────────────────>│                  │
│                  │   Подтверждение приема            │                  │
│                  │<──────────────────────────────────┤                  │
│                  │   Подтверждение обработки         │                  │
│                  │<──────────────────────────────────┤                  │
│                  │                                   │                  │
│  Отправитель     │ ВОПРОСИТЕЛЬНАЯ транзакция         │  Получатель-     │
│                  │                                   │                  │
│                  │          Запрос данных            │                  │
│  сообщений       ├──────────────────────────────────>│  сообщений       │
│                  │   Подтверждение приема            │                  │
│                  │<──────────────────────────────────┤                  │
│                  │   Запрошенные данные              │                  │
│                  │<──────────────────────────────────┤                  │
│                  │                                   │                  │
│                  │ ПОВЕЛИТЕЛЬНАЯ транзакция          │                  │
│                  │                                   │                  │
│                  │       Требование действия         │                  │
│                  ├──────────────────────────────────>│                  │
│                  │   Подтверждение приема            │                  │
│                  │<──────────────────────────────────┤                  │
│                  │   Подтверждение обработки и       │                  │
│                  │<──────────────────────────────────┤                  │
│                  │   выполнения                      │                  │
└──────────────────┘                                   └──────────────────┘

Рисунок 5 Классификация транзакций и сообщений

В ответ на исходное сообщение (описательное, повелительное или запрос) принимающая система отправляет последовательно два ответа.

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

Второй ответ посылается после прикладной обработки исходного сообщения "по существу" и называется подтверждением прикладной обработки. В подтверждении прикладной обработки указывается код, по которому можно определить, обработано исходное сообщение или в обработке отказано и по какой причине. Для вопросительных транзакций в случае успешной обработки возвращается ответ на запрос, содержащий запрошенные сведения или информацию о том, что запрошенная информация отсутствует. Подтверждение прикладной обработки формирует ЦС ЕРЗ. В качестве описательных транзакций в ИС ЕРЗ выступают транзакции изменения данных о застрахованных лицах. В дальнейшем такие транзакции будем называть транзакциями изменения данных в ЕРЗ.

Вопросительные сообщения (запросы) посылаются в том случае, когда ТФОМС для выполнения той или иной функции требуется информация о застрахованном лице, которой он не располагает, но может получить из ЦС ЕРЗ.

Повелительные сообщения в настоящей реализации не используются.

6.1.1.2 Правила составления сообщений

6.1.1.2.1 Состав сообщений и общие правила кодирования; типы данных

Сообщение состоит из сегментов, обозначаемых трехбуквенными именами. При XML-кодировании обозначения сегментов становятся именами соответствующих XML-элементов. Некоторые группы сегментов могут повторяться. При XML-кодировании такие повторяющиеся группы объединяются в XML-элемент, имя которого также указывается в описании структуры сообщения.

Для формирования сообщений используется XML-кодирование с кодовой страницей Windows-1251. Каждой группе событий, информация о которых передается в информационных сообщениях или запрашивается в сообщениях запроса, соответствует определенная структура сообщений. Для каждой структуры сообщений используется отдельная xml-схема. От имени структуры сообщения образуются имена файлов xml-схем и имена корневых элементов соответствующих сообщений. Например, если сообщение имеет структуру ADT_A01, то корневой элемент этого сообщения имеет имя <ADT_A01>, а сама структура описывается xml-схемой, хранящейся в файле ADT_A01.xsd.

Сегменты сообщений составляются из полей, в которых передаются конкретные элементы информации. Каждое поле имеет логическое имя, в котором кратко обозначено общее назначение поля. Имена полей используются только при описании сегментов сообщений. При формировании и интерпретации сообщений поля определяются по их порядковому номеру в сегменте. В связи с этим при XML-кодировании для передачи значения поля в состав элемента, соответствующего сегменту, включается элемент, имя которого составляется из имени сегмента и порядкового номера поля, разделенных точкой.

Пример.

<BHS><BHS.11>1903ED97-F5C4-41C5-8035-C6606A9BD7C2</BHS.11></BHS>

Сегмент с именем BHS ("Заголовок пакета сообщений"), в который вложено поле N 11 ("Идентификатор пакета"). Значение поля - GUID 1903ED97-F5C4-41C5-8035-C6606A9BD7C2.

Значениями полей могут быть данные определенных типов. Типы данных бывают простыми и составными (комплексными). Значение простого типа данных состоит из атомарного значения, на которое могут быть наложены ограничения. Значения комплексных типов данных состоят из компонентов, которые, так же, как и поля сегментов, имеют имена, использующиеся при описании типов данных. При XML-кодировании значение каждого компонента комплексного типа указывается в xml-элементе, имя которого составляется из имени типа данных и порядкового номера компонента, разделенных точкой.

Пример.

    <BHS.6>
      <HD.1>47</HD.1>
      <HD.2>1.2.643.2.40.3.3.1.0</HD.2>
      <HD.3>ISO</HD.3>
    </BHS.6>

Поле сегмента BHS с порядковым номером 6 ("Учреждение-получатель пакета") заполнено значением, имеющим тип данных HD ("Иерархический идентификатор"), который, в свою очередь, имеет три компонента.

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

Пример.

      <PID.5>
        <XPN.1>
          <FN.1>Степанов</FN.1>
        </XPN.1>
        <XPN.2>Олег</XPN.2>
        <XPN.3>Михайлович</XPN.3>
        <XPN.7>L</XPN.7>
      </PID.5>

Поле сегмента PID ("Идентификация застрахованного лица") с порядковым номером 5 ("Фамилия, имя, отчество застрахованного лица") имеет комплексный тип данных XPN ("Фамилия, имя, отчество"), в котором заполнены четыре компонента: 1-й ("Фамилия"), 2-й ("Имя"), 3-й ("Отчество") и 7-й ("Тип ФИО"; в данном случае указан тип L (Legal) - "ФИО, официально признанные в настоящий момент"). 1-й компонент типа данных XPN имеет комплексный тип FN ("Фамилия"), из которого используется только первый компонент (первый субкомпонент первого компонента поля PID.5).

Описания типов данных, используемых в сообщениях стандарта ISO 27931, даны в разделе 6.1.2.

6.1.1.2.2 Соглашения об обозначениях и сокращениях, принятых при описании структуры и состава сообщений

При описании структур сообщений и заполнения сегментов приняты следующие соглашения.

Имя сегмента или группа сегментов, взятые в фигурные скобки {}, означают возможность повторения сегмента или группы сегментов.

Имя сегмента или группа сегментов, взятые в квадратные скобки [], означают необязательность сегмента или группы сегментов.

Обязательные для заполнения поля сегментов помечены значением Да в столбце "Обяз. поле". Имена таких полей выделены жирным шрифтом.

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

Компоненты и субкомпоненты, обязательные для заполнения, помечены значением Да в столбцах "Обяз. кмп" ("Обяз. субкомп.") и выделены жирным шрифтом. Обязательность компонента для необязательного поля означает, что если поле включено в состав сегмента, то оно должно включать в себя обязательный компонент. Аналогичное замечание верно и для обязательных субкомпонентов необязательных компонентов.

В столбце "Экз." указывается:

0..1, если поле не повторяется (для необязательных полей),

1, если поле не повторяется (для обязательных полей),

другое число, если поле может повторяться и описываемое значение должно быть в экземпляре поля с указанным порядковым номером,

0..N, если поле может повторяться не более, чем указанное количество раз,

0..*, если поле может повторяться неограниченное число раз, являясь необязательным,

1..*, если поле может повторяться неограниченное число раз, являясь обязательным.

Если столбца "Экз." в описании сегмента нет, то это означает, что в сегменте нет повторяющихся полей.

Описание правил обработки полей и ошибок форматно-логического контроля указаны после каждой таблицы с описанием правил заполнения сегмента.

6.1.1.3 Пакетная обработка сообщений

Взаимодействие прикладных систем в ИС ОМС осуществляется пакетными файлами, каждый из которых включает в себя несколько сообщений. Для пакетов также используется XML-кодирование.

В настоящем разделе описана структура пакетного файла и входящих в него сегментов заголовка и конца пакета.

Пакетные файлы имеют структуру, показанную ниже.

    Элементы                      │      Описание
                                  │
    <тип пакета>                  │ Корневой элемент пакетного XML-файла  -
                                  │ первая строка файла
           <BHS>...</BHS>         │ Заголовок пакета
                 [{               │--- Нуль или более сообщений
                              ... │--- Сегменты сообщения
                 }]               │--- Конец сообщения
           <BTS>...</BTS>         │ Сегмент конца пакета
    </тип пакета>                 │ Последняя строка файла

6.1.1.3.1 Общие требования к пакету и составляющим его сообщениям

6.1.1.3.1.1 Версия протокола пакета

В каждый пакет должны включаться сообщения только одной версии протокола, которая считается версией протокола пакета. Версия протокола пакета должна быть указана в качестве значения атрибута oms:version. Если версия протокола пакета не указана, то считается, что в пакет включены сообщения версии 3.0.

6.1.1.3.1.2 Прикладная обработка пакета

Все сообщения пакета должны иметь один и тот же тип прикладной обработки, указанный в поле MSH.11. Данное требование на этапе ФЛК не проверяется, однако, если оно не выполнено, то пакет отвергается целиком на этапе прикладной обработки.

6.1.1.3.2 Сегмент BHS - "Заголовок пакета"

6.1.1.3.2.1 Структура сегмента BHS

Структура сегмента заголовка пакета сообщений BHS описана в таблице 25.

Таблица 25 Сегмент заголовка пакета BHS (Batch Header Segment)

Таблица 26 Правила формирования кодов учреждений и приложений, являющихся отправителями и получателями пакетов сообщений (необязательные компоненты указаны серым курсивом)

Описание ошибок ФЛК для сегмента BHS приведено в классификаторе Q010.

6.1.1.3.3 Сегмент BTS - "Конец пакета"

Структура сегмента конца пакета сообщений BTS описана в Таблице 27. Ошибки ФЛК для данного сегмента приведены в классификаторе Q012.

Таблица 27 Сегмент конца пакета BTS (Batch Trailer Segment)

6.1.1.3.4 Подтверждающие пакеты

Ответный пакет имеет такую же структуру, как и исходный пакет, и состоит из сообщений, каждое из которых является ответом на одно из посланных сообщений.

6.1.1.4 Структура и служебные сегменты исходных сообщений

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

6.1.1.4.1 Сегмент MSH - "Заголовок сообщения"

6.1.1.4.1.1 Структура сегмента MSH

Сегмент MSH обязателен во всех сообщениях и не повторяется. Повторяющихся полей в сегменте нет.

Таблица 28 Заполнение сегмента MSH для исходных сообщений и запросов

Примечание

Значения полей MSH.3, MSH.4, MSH.5, MSH.6 являются обязательными только в том случае, если сообщение отсылается самостоятельно, не будучи вложенным в пакет. Для вложенных в пакет сообщений эти поля указывать не обязательно. В таком случае считается, что их значения совпадают со значениями соответствующих полей сегмента заголовка пакета (xml-имена BHS.3, BHS.4, BHS.5, BHS.6). Указания по заполнению значений этих полей даны при описании структуры сегмента BHS (см. таблицу 26).

Описание ошибок ФЛК для сегмента MSH приведено в классификаторе Q011.

6.1.1.4.2 Сегмент EVN - "Тип события"

6.1.1.4.2.1 Структура сегмента EVN

Сегмент EVN обязателен и не повторяется. Все указанные поля обязательны и включаются в сегмент ровно один раз.

Таблица 29 Заполнение сегмента EVN

Описание ошибок ФЛК для сегмента EVN приведено в классификаторе Q004.

6.1.1.5 Структура и служебные сегменты ответных сообщений

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

Для большинства исходных сообщений этой информации достаточно в сообщениях подтверждения приема или прикладной обработки. В связи с этим в стандарт включено сообщение ACK - "Сообщение общего подтверждения", структура которого приведена ниже.

            ACK/\код-события/\ACK    │ Общее подтверждение
            <ACK>                    │
                  <MSH>...</MSH>     │ Заголовок сообщения
                  <MSA>...</MSA>     │ Подтверждение сообщения
                  [{<ERR>...</ERR>}] │ Ошибка
            </ACK>                   │

Все подтверждения приема, подтверждения прикладной обработки и ответы на запрос начинаются так же, как описанное выше сообщение общего подтверждения. Если исходное сообщение требует передачи в сообщении подтверждении дополнительных данных, то эти данные включаются в сегменты, которые вставляются после сегмента ERR. Туда же включаются дополнительные сегменты, содержащие ответ на запрос в сообщениях, отвечающих на запросы.

6.1.1.5.1 Сегмент MSH - "Заголовок сообщения"

Таблица 30 Заполнение сегмента MSH для сообщений подтверждения приема и сообщений подтверждения прикладной обработки

6.1.1.5.2 Сегмент MSA - "Подтверждение сообщения"

Сегмент подтверждения сообщения MSA содержит информацию, передаваемую в подтверждениях приема, прикладной обработки и в ответах на запросы.

Таблица 31 Сегмент MSA - "Подтверждение сообщения"

6.1.1.5.3 Сегмент ERR - "Информация об ошибке"

В сегменте ERR передаются комментарии по поводу возникших ошибок, если таковые имели место. Сегмент может использоваться также для передачи информационных сообщений и предупреждений. В таблице 32 даны правила заполнения полей сегмента.

Таблица 32 Сегмент ERR - "Информация об ошибке"

--------------------------------

<1> Для процедур SQL-Server код составляется из двух компонентов, разделенных точкой: 1) код ошибки или сообщения (ERROR_NUMBER), 2) статус сообщения (ERROR_STATE). Если статус у сообщения не предусмотрен, то код сообщения передается без точки.

6.1.1.6 Общие сведения о запросах и ответах на них

Запросы могут иметь параметры, для спецификации которых могут применяться различные способы. В ИС ЕРЗ применяются запросы с простыми параметрами, предполагающие передачу параметров запроса в качестве значений последующих полей специального сегмента QPD, разного для разных запросов. Механизм запроса с простыми параметрами аналогичен механизму вызова хранимой процедуры базы данных.

В ответ на запрос возвращается сообщение, состоящее из сегментов ISO 27931. Это сообщение по своей структуре подобно сообщениям, описанным выше, и содержит те же сегменты.

6.1.1.6.1 Профили запросов

Под профилем запроса понимается описание запроса, содержащее следующие данные:

- Введение, в котором указывается точное имя запроса и словесное описание его назначения, а также тип запроса и тип ответа на запрос.

- Грамматика запроса, определяющая сегменты, которые могут быть переданы отправителем сообщения. Для каждого поля, входящего в указанные сегменты, в профиле запроса точно определяется, как переданное в этом поле значение должно интерпретироваться действующим лицом, которое должно отвечать на запрос.

- Грамматика ответа на запрос, определяющая сегменты, из которых должен быть сконструирован ответ на запрос.

6.1.1.6.2 Особенности обработки запросов

Для получения ответа на запрос прикладная информационная система передает в шлюз РС сообщение со структурой, предусмотренной грамматикой выбранного запроса. Шлюз РС производит форматно-логический контроль сообщения и возвращает сообщение ACK с подтверждением приема. Если исходное сообщение с запросом содержит ошибки ФЛК, то информация об ошибках включается в сообщение подтверждения приема. Если сообщение не содержит ошибок ФЛК, то оно при необходимости псевдонимизируется и передается в ЦС ЕРЗ, который возвращает ответ на запрос в сообщении со структурой, предусмотренной грамматикой ответа на запрос.

Структура подтверждения приема для всех запросов одинакова и соответствует структуре общего подтверждения:

            ACK/\код-запроса/\ACK    │ Подтверждение приема запроса
            <ACK>                    │
                  <MSH>...</MSH>     │ Заголовок сообщения
                  <MSA>...</MSA>     │ Подтверждение сообщения
                  [{<ERR>...</ERR>}] │ Ошибка ФЛК.
            </ACK>                   │

Сегменты сообщений подтверждения приема описаны в пункте 6.1.1.5. Специальных особенностей в их заполнении для прикладного подтверждения сообщений с запросами нет.

6.1.2 Типы данных, используемые в сообщениях

6.1.2.1 Простые типы данных

Состав простых типов данных сообщений стандарта ISO 27931:2009, используемых в ИС ЕРЗ ОМС, показан на рисунке 6, а их назначение и формат записи значений даны в таблице 33. В столбце "Примечания к реализации" даны дополнительные требования, накладываемые на тип данных в ИС ОМС по сравнению со стандартом ISO.

┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│  DT  │ │  DTM │ │  ID  │ │  IS  │ │  NM  │ │  ST  │ │  SI  │ │  TX  │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘

Рисунок 6 Простые типы данных сообщений стандарта

ISO 27931:2009

Таблица 33 Назначение и формат простых типов данных стандарта ISO 27931:2009

6.1.2.2 Составные типы данных

Составные типы данных сообщений стандарта ISO 27931:2009, используемые в ИС ОМС, показаны на рисунке 7.

┌──────────────────────────────────────────────────────┐   ┌──────────────────────────────────────────────────────┐
│                         CNE                          │   │                         CWE                          │
├──────────────────────────────────────────────────────┤   ├──────────────────────────────────────────────────────┤
│+идентификатор : ST [1]                               │   │+идентификатор : ST [0..1]                            │
│+текст : ST [0..1]                                    │   │+текст : ST [0..1]                                    │
│+имя системы кодирования : ID [0..1]                  │   │+имя системы кодирования : ID [0..1]                  │
│+альтернативный идентификатор : ST [0..1]             │   │+альтернативный идентификатор : ST [0..1]             │
│+альтернативный текст : ST [0..1]                     │   │+альтернативный текст : ST [0..1]                     │
│+имя альтернативной системы кодирования : ID [0..1]   │   │+имя альтернативной системы кодирования : ID [0..1]   │
│+версия системы кодирования : ST [0..1]               │   │+версия системы кодирования : ST [0..1]               │
│+версия альтернативной системы кодирования : ST [0..1]│   │+версия альтернативной системы кодирования : ST [0..1]│
│+исходный текст [0..1]                                │   │+исходный текст [0..1]                                │
└──────────────────────────────────────────────────────┘   └──────────────────────────────────────────────────────┘
  ┌──────────────────────────────────────────────────┐                 ┌──────────────────────────────┐
  │                       CX                         │                 │               DR             │
  ├──────────────────────────────────────────────────┤                 ├──────────────────────────────┤
  │+идентификатор : ST [1]                           │                 │+начало диапазона : DTM [0..1]│
  │+контрольная цифра идентификатора : ST [0..1]     │                 │+конец диапазона : DTM [0..1] │
  │+система кодирования контрольной цифры : ID [0..1]│                 └──────────────────────────────┘
  │+присвоившая организация : HD [0..1]              │          ┌──────────────────────────────────────────────┐
  │+тип идентификатора : ID [0..1]                   │          │                     EI                       │
  │+место присвоения идентификатора : HD [0..1]      │          ├──────────────────────────────────────────────┤
  │+дата начала действия : DT [0..1]                 │          │+идентификатор : ST [0..1]                    │
  │+срок действия : DT [0..1]                        │          │+пространство имен : IS [0..1]                │
  │+юрисдикция присвоения идентификаторов : CWE      │          │+универсальный идентификатор : ST [0..1]      │
  │+присвоившая структурная единица : CWE [0..1]     │          │+тип универсального идентификатора : ID [0..1]│
  └──────────────────────────────────────────────────┘          └──────────────────────────────────────────────┘
       ┌──────────────────────────────────────┐                    ┌────────────────────────────────────────┐
       │                  ERL                 │                    │                   FN                   │
       ├──────────────────────────────────────┤                    ├────────────────────────────────────────┤
       │+имя сегмента : ST [0..1]             │                    │+фамилия : ST [1]                       │
       │+порядковый номер сегмента : NM [0..1]│                    │+префикс собственной фамилии : ST [0..1]│
       │+номер поля : NM [0..1]               │                    │+собственная фамилия : ST [0..1]        │
       │+номер повторения поля : NM [0..1]    │                    │+префикс фамилии супруга : ST [0..1]    │
       │+номер компонента : NM [0..1]         │                    │+фамилия супруга : ST [0..1]            │
       │+номер субкомпонента : NM [0..1]      │                    └────────────────────────────────────────┘
       └──────────────────────────────────────┘                          ┌────────────────────────────┐
                                                                         │             QIP            │
   ┌──────────────────────────────────────────────┐                      ├────────────────────────────┤
   │                      HD                      │                      │+имя параметра : ST [1]     │
   ├──────────────────────────────────────────────┤                      │+значение параметра : ST [1]│
   │+код : IS [0..1]                              │                      └────────────────────────────┘
   │+универсальный идентификатор : ST [0..1]      │                 ┌──────────────────────────────────────┐
   │+тип универсального идентификатора : ID [0..1]│                 │                  SAD                 │
   └──────────────────────────────────────────────┘                 ├──────────────────────────────────────┤
                                                                    │+адрес в населенном пункте : ST [0..1]│
  ┌────────────────────────────────────────────────┐                │+улица : ST [0..1]                    │
  │                     XAD                        │                │+дом : ST [0..1]                      │
  ├────────────────────────────────────────────────┤                └──────────────────────────────────────┘
  │+адрес в населенном пункте : SAD [0..1]         │            ┌──────────────────────────────────────────────┐
  │+другое указание : ST [0..1]                    │            │                     VID                      │
  │+населенный пункт : ST [0..1]                   │            ├──────────────────────────────────────────────┤
  │+область : ST [0..1]                            │            │+идентификатор версии : ID [1]                │
  │+почтовый индекс : ST [0..1]                    │            │+код интернационализации : CWE [0..1]         │
  │+страна : ID [0]                                │            │+идентификатор локализованной версии : CWE [1]│
  │+тип адреса : ID [0..1]                         │            └──────────────────────────────────────────────┘
  │+другое географическое обозначение : ST [0..1]  │          ┌──────────────────────────────────────────────────┐
  │+код административной единицы : IS [0..1]       │          │                       XON                        │
  │+избирательный участок : IS [0..1]              │          ├──────────────────────────────────────────────────┤
  │+код представления адреса : ID [0..1]           │          │+наименование организации : ST [0..1]             │
  │+срок действия адреса : DR [0..1]               │          │+тип наименования : IS [0..1]                     │
  │+дата начала действия : DTM [0..1]              │          │+идентификатор : NM [1]                           │
  │+срок действия : DTM [0..1]                     │          │+контрольная цифра идентификатора : ST [0..1]     │
  │+причина прекращения действия : CWE [0..1]      │          │+система кодирования контрольной цифры : ID [0..1]│
  │+признак временного адреса : ID [0..1]          │          │+присвоившая организация : HD [0..1]              │
  │+признак неправильного адреса : ID              │          │+тип идентификатора : CWE [0..1]                  │
  │+тип использования адреса : ID [0..1]           │          │+место присвоения идентификатора : HD [0..1]      │
  │+адресат : ST [0..1]                            │          │+код представления наименования : ID [0..1]       │
  │+примечание : ST [0..1]                         │          │+идентификатор организации : ST [0..1]            │
  │+порядок предпочтения : NM [0..1]               │          └──────────────────────────────────────────────────┘
  │+код конфиденциальности : CWE [0..1]            │                 ┌─────────────────────────────────────┐
  │+идентификатор адреса : EI [0..1]               │                 │                 XPN                 │
  └────────────────────────────────────────────────┘                 ├─────────────────────────────────────┤
                                                                     │+фамилия : FN [0..1]                 │
 ┌───────────────────────────────────────────────────┐               │+имя : ST [0..1]                     │
 │                         XTN                       │               │+отчество : ST [0..1]                │
 ├───────────────────────────────────────────────────┤               │+суффикс : ST [0..1]{union}          │
 │+номер телефона [0]                                │               │+префикс : ST [0..1]                 │
 │+код использования телекоммуникаций : ID [0..1]    │               │+ученая степень : IS [0..1]          │
 │+тип телекоммуникационного оборудования : ID [0..1]│               │+код типа ФИО : ID [0..1]            │
 │+коммуникационный адрес : ST [0..1]                │               │+код представления ФИО : ID [0..1]   │
 │+код страны : NM [0..1]                            │               │+контекст ФИО : CWE [0..1]           │
 │+код региона : NM [0..1]                           │               │+срок действия ФИО : DR [0..1]       │
 │+местный номер телефона : NM [0..1]                │               │+порядок сборки ФИО : ID [0..1]      │
 │+дополнительный номер : NM [0..1]                  │               │+дата начала действия : DT [0..1]    │
 │+произвольный текст : ST [0..1]                    │               │+срок действия : DT [0..1]           │
 │+префикс дополнительного номера : ST [0..1]        │               │+профессиональный суффикс : ST [0..1]│
 └───────────────────────────────────────────────────┘               └─────────────────────────────────────┘

Рисунок 7 Составные типы данных сообщений стандарта

ISO 27931:2009

Далее описана структура каждого из составных типов данных. Некоторые компоненты являются обязательными; такие компоненты обязательно должны быть указаны в любом поле данного типа. Необязательные компоненты типа данных могут быть обязательными или условно-обязательными в конкретном поле данного типа, что указано в указаниях по заполнению соответствующего поля.

Серым курсивом указаны компоненты типа данных, не использующиеся в ИС ОМС.

6.1.2.2.1 Типы данных CNE и CWE

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

В полях типов CNE и CWE могут одновременно передаваться код из местной системы кодирования (в полях CNE.1 - CNE.3, CNE.7 или CWE.1 - CWE.3, CWE.7) и код из унифицированной (альтернативной) системы кодирования (в полях CNE.4 - CNE.6, CNE.8 или CWE.4 - CWE.6, CWE.8). Эти коды должны означать одно и то же понятие. Такая возможность в ИС ЕРЗ пока не используется.

Таблица 34 Состав типов данных CNE и CWE

6.1.2.2.2 Тип данных CX

Расширенный составной идентификатор.

Таблица 35 Состав типа данных CX

6.1.2.2.3 Тип данных DR

Период времени.

Таблица 36 Состав типа данных DR

6.1.2.2.4 Тип данных EI

Идентификация сущности (субъекта, объекта, понятия системы кодирования). В ИС ЕРЗ ОМС используется для идентификации ОИД систем кодирования в пространстве ОИД, задаваемом используемым справочником справочников. По этой причине компоненты EI.2 - EI.4 могут быть опущены и не используются в сообщениях.

Таблица 37 Состав типа данных EI

6.1.2.2.5 Тип данных ERL

Указатель позиции ошибки.

Таблица 38 Состав типа данных ERL

6.1.2.2.6 Тип данных FN

Фамилия. Тип данных, использующийся только в составе других составных типов данных и не разрешенный к использованию в качестве типа данных поля.

Таблица 39 Состав типа данных FN

6.1.2.2.7 Тип данных HD

Иерархический идентификатор. В ИС ЕРЗ ОМС используется:

а) для обозначения учреждений и приложений, участвующих в информационном обмене;

б) для обозначения кодируемых понятий при обмене сообщениями об изменениях НСИ.

В обоих вариантах использования для кодирования понятий используется парадигма уникального идентификатора, состоящего из пары {код, уникальный идентификатор системы кодирования}. В качестве уникального идентификатора системы кодирования используется ОИД, что в соответствии со стандартом ISO 27931 обозначается константой "ISO" в компоненте HD.3. Кроме того, в соответствии с требованиями стандарта ISO 27931 компоненты HD.2 и HD.3 могут присутствовать или не присутствовать в составе значения типа данных только вместе.

Таблица 40 Состав типа данных HD

6.1.2.2.8 Тип данных QIP

Параметр запроса. Используется для передачи нестандартных параметров отчетов.

Таблица 41 Состав типа данных QIP

6.1.2.2.9 Тип данных SAD

Адрес в населенном пункте. Тип данных, использующийся только в составе других составных типов данных и не разрешенный к использованию в качестве типа данных поля.

Таблица 42 Состав типа данных SAD

6.1.2.2.10 Тип данных VTO

Идентификатор версии протокола. Составной тип данных, позволяющий указать версию протокола ISO 27931, страну, в которой произведена локализация версии и конкретный вариант локализации.

Таблица 43 Состав типа данных VID

6.1.2.2.11 Тип данных XAD

Структурированный адрес. Поля данного типа используются для передачи сведений об адресе регистрации по месту жительства лица, состоящего на учете.

Таблица 44 Состав типа данных XAD

6.1.2.2.12 Тип данных XON

Наименование организации и ее код.

Таблица 45 Состав типа данных XON

6.1.2.2.13 Тип данных XPN

Фамилия, имя, отчество.

Таблица 46 Состав типа данных XPN

6.2 Протокол обмена в формате CSV

6.2.1 Общие сведения о протоколе обмена в формате CSV

Формат CSV используется для обмена большими объемами данных между ТФОМС и ФОМС для решения следующих задач:

1) сверка данных между Региональным и Центральным сегментами ЕРЗ,

2) загрузка сведений о прикреплении застрахованных лиц к медицинским организациям.

6.2.1.1 Общая схема обмена данными

Общая схема обмена данными в формате CSV приведена на рисунке 8.

┌──────────────────┐                                   ┌──────────────────┐
│                  │                                   │                  │
│                  │         Исходное сообщение        │                  │
│Отправитель       ├──────────────────────────────────>│Получатель-       │
│                  │            Журнал ФЛК             │                  │
│                  │<──────────────────────────────────┤                  │
│сообщений         │     Журнал обработки (загрузки)   │сообщений         │
│                  │<──────────────────────────────────┤                  │
│                  │                                   │                  │
└──────────────────┘                                   └──────────────────┘

Рисунок 8 Классификация сообщений CSV-протокола

Отправитель (ТФОМС) посылает в адрес получателя (ФОМС) через шлюз РС ЕРЗ исходное сообщение в формате CSV. Шлюз производит форматно-логический контроль сообщения и возвращает журнал форматно-логического контроля, содержащий описания ошибок исходного сообщения. Если ошибок нет, то исходное сообщение псевдонимизируется и отправляется в адрес ЦС ЕРЗ. После обработки "по существу" ЦС ЕРЗ возвращает журнал обработки (журнал загрузки), содержащий сведения о результатах обработки исходного сообщения.

6.2.1.2 Структура исходного сообщения

Формат CSV (commaseparatedvalues - текстовый с разделителями) - это формат, специально предназначенный для обмена большими объемами записей, имеющих однородную структуру. Каждая запись занимает отдельную строку файла, в которой передаваемые значения отделяются друг от друга заданным разделителем.

К csv-файлам, которые используются при обменах в ЕРЗ, предъявляются следующие требования.

1 При кодировании файла следует использовать кодовую страницу Windows-1251.

2 В первой строке должны быть перечислены имена атрибутов, разделенные точкой с запятой (";" код 5910). Перечень атрибутов, порядок их следования, назначение, наименования и требования к правилам заполнения определены в разделах, посвященных конкретным типам сообщений.

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

4 Признаком окончания метаданных служит специальная служебная строка-разделитель, содержащая следующую последовательность символов:

(((|||)))

(последовательность кодов: 4010, 4010, 4010, 12410, 12410, 12410, 4110, 4110, 4110,)

5 После служебной строки следуют строки с передаваемыми значениями.

Требования к заполнению строк со значениями атрибутов:

- Значения атрибутов должны следовать строго в том порядке, который задан для конкретного сообщения.

- Значения отделяются друг от друга знаком "точка с запятой" (";" код 5910).

- Каждое отдельное значение должно быть взято в кавычки с обеих сторон (код 3410).

- Обязательные для заполнения значения помечены значением Да в графе "Обяз.". Имена таких атрибутов выделены жирным шрифтом.

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

- Необязательные атрибуты помечены графе "Обяз." значением Нет. Значения таких атрибутов могут отсутствовать.

- Если значение отсутствует, то на его месте следует вставить очередную точку с запятой (кавычки в таком случае не требуются).

- Кавычки на месте отсутствующих значений в конце строки ставить не обязательно.

6 Строки файла должны отделяться друг от друга парой знаков "возврат каретки" и "перевод строки" (коды 1310 и 1010), следующих непосредственно друг за другом.

7 Файл не должен начинаться со знаков "возврат каретки" и "перевод строки" или заканчиваться этими знаками. Включение в файл пустых строк (повторение пар "возврат каретки" и "перевод строки" несколько раз непосредственно друг за другом) не допускается.

8 Если знаки, являющиеся разделителями (точка с запятой и кавычки) встречаются внутри передаваемого значения, то перед ними должен быть вставлен знак "обратная косая черта" ("\"; код 9210). Одиночный знак "\" должен быть заменен парой знаков "\\". Правила замены даны в таблице 47.

Таблица 47 Замена специальных знаков при передаче csv-файлов

6.2.1.3 Структура журнала форматно-логического контроля

Если в исходном сообщении не обнаружено ошибок ФЛК, то ответный файл будет содержать только один символ - латинскую букву "N".

Если в исходном файле обнаружены ошибки ФЛК, то для каждой строки исходного файла, содержащей ошибки, в журнал ФЛК включается строка, содержащая коды ошибок, обнаруженных в строке исходного файла.

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

6.2.1.4 Структура журнала прикладной обработки

Структура журнала прикладной обработки является специфической для каждого сообщения и описана в соответствующем разделе.

В журнале прикладной обработки могут указываться ошибки прикладной обработки.

6.2.2 Правила именования файлов обмена

Сообщения в формате csv должны передаваться в файлах, имена которых имеют структуру, указанную в таблице 48.

Обозначения, принятые в таблице 48:

<код территории> - пятизначный код ОКАТО территории прикрепления (из системы кодирования 1.2.643.2.40.3.3.1);

<год> - год, данные за который посылаются в сообщении;

<порядковый номер сообщения> - трехзначный порядковый номер сообщения данного типа. Сообщения (файлы) должны нумероваться последовательными целыми числами, начиная с 001.

Таблица 48 Правила именования файлов обмена

Пример.

M46000002.csv - файл для загрузки данных о прикреплении застрахованных лиц к медицинским организациям из Московского областного фонда ОМС; вторая выгрузка (часть).

6.3 Дополнительные сведения

6.3.1 Перечень и состав используемых систем кодирования

Таблица 49 Коды фондов ОМС, соответствующих им территорий страхования (коды ОКАТО, дополненные справа нулями до 5 знаков) и Федеральных округов