Приказ ФФОМС от 09.09.2016 N 169 "О внесении изменений в приказ Федерального фонда обязательного медицинского страхования от 7 апреля 2011 г. N 79"

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

ПРИКАЗ
от 9 сентября 2016 г. N 169

О ВНЕСЕНИИ ИЗМЕНЕНИЙ
В ПРИКАЗ ФЕДЕРАЛЬНОГО ФОНДА ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО
СТРАХОВАНИЯ ОТ 7 АПРЕЛЯ 2011 Г. N 79

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

1. Внести в приказ Федерального фонда обязательного медицинского страхования от 07.04.2011 N 79 "Об утверждении Общих принципов построения и функционирования информационных систем и порядка информационного взаимодействия в сфере обязательного медицинского страхования" изменения, изложив его в редакции согласно приложению к настоящему Приказу.

2. Признать приказ Федерального фонда обязательного медицинского страхования от 26.12.2013 N 276 "О внесении изменений в приказ ФОМС от 07.04.2011 N 79" утратившим силу.

3. Контроль за исполнением настоящего приказа возложить на заместителя председателя Ю.А. Нечепоренко.

Председатель
Н.Н.СТАДЧЕНКО

Приложение

Утверждено
приказом ФОМС
от 7 апреля 2011 г. N 79
(в редакции приказа ФОМС
от "__" сентября 2016 г. N ___)

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

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

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

2 Сокращения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Территориальные фонды обязательного медицинского страхования осуществляют ведение своих сегментов единых реестров и справочника, указанных в подпунктах 16 - 19 Таблицы 4 настоящего документа, на корпоративном сайте Федерального фонда ОМС http://web.ffoms.ru (раздел Справочники и реестры) или выкладывают изменения в виде файла формата XML (кодовая страница Windows-1251).

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

┌─────────────────────────────┐         ┌────────────────────────────────┐
│              ┌─────────────┐│         │                                │
│              │Использование││         ├───────────┐   ┌─────────────┐  │
├───────────┐  │ в своих ИС  ││         │ Страховые │   │Использование│  │
│Медицинские│  └─────────────┘│         │медицинские│   │ в своих ИС  │  │
│организации│        /\       │         │организации│   └─────────────┘  │
└───────────┴─────────┼───────┘         └───────────┴─────────/\─────────┘
┌─────────────────────┼───────┐                               │
│                     │       │  ┌────────────────────────────┼──────────┐
│          ┌──────────┴───────┼──┼────────────────────────────┘          │
│          │                  │  │                                       │
│   ┌──────┴──────┐           │  │                                       │
│   │Размещение на│           │  │                                       │
│┌─>│ официальном │<──────────┼┬─┼───────────────────┐                   │
││  │ сайте ТФОМС │           ││ │                   │                   │
││  └─────────────┘           ││ │                   │                   │
│└─────────────────────────┐  ││ │  ┌────────────────┴───────────┐       │
│ ┌──────────────────────┐ │  ││ │  │Размещение на корпоративном │       │┌────────────────────┐
│ │   Ведение сегмента   │ │  ││ │  │   Интернет-сайте ФОМС в    │       ││   ┌───────────────┐│
│ │     Справочника      ├─┤  ││ │  │   разделе Справочники и    │       ││   │  Ведение НСИ, ││
│ │территориальных фондов│ │  ││ │  │          реестры           │       ││   │  находящейся  ││
│ │        ОМС           │ │  ││ │  └────────────────────────────┘       ││┌──┤    в зоне     ││
│ └──────────────────────┘ │  ││ │                     /\                │││  │ответственности││
│ ┌──────────────────────┐ │  ││ │               ┌──────│                │││  │  организации  ││
│ │   Ведение сегмента   │ │  ││ │     ┌─────────┴──────┴─────┐          │││  └───────────────┘│
│ │   Единого реестра    │ │  ││ │     │За исключением Единого│          │││                   │
│ │страховых медицинских │ │  ││ │     │  реестра Экспертов   │          │││                   │
│ │     организаций,     │ │  ││ │     │ качества медицинской │          │││                   │
│ │    осуществляющих    ├─┤  ││ │     │        помощи        │          │││                   │
│ │ деятельность в сфере │ │  ││ │     └────────────┬─────────┘          │││                   │
│ │    обязательного     │ │  ││ │   ┌───────────┐  │ ┌────────────┐     │││   ┌───────────────┤
│ │     медицинского     │ │  ││ │   │  Ведение  │  │ │Формирование│     │││   │  Организация, │
│ │     страхования      │ │  ││ │   │  Единых   │  │ │федерального│     │││   │ ответственная │
│ └──────────────────────┘ ├──┼┼─┼──>│реестров и ├──┴─┤ пакета НСИ │<────┼┼┘   │ за ведение и  │
│ ┌──────────────────────┐ │/\││ │   │справочника│    │    <1>     │  /\ ││    │разработку НСИ │
│ │   Ведение сегмента   │ │ │││ │   └───────────┘    └────────────┘  │  │└────┴───────────────┘
│ │   Единого реестра    │ │ │││ │                                    │  │
│ │     медицинских      │ │ │││ │                                    │  │
│ │     организаций,     │ │ │││ │                                    │  │
│ │    осуществляющих    ├─┘ │││ │       ┌───────────────────┐        │  │
│ │ деятельность в сфере │   │││ │       │   Ведение НСИ,    │        │  │
│ │    обязательного     │   │││ │       │находящейся в зоне │        │  │
│ │     медицинского     │   │││ │       │  ответственности  ├────────┘  │
│ │     страхования      │   │││ │       │Федерального фонда │           │
│ └──────────────────────┘   │││ │       │        ОМС        │           │
│ ┌──────────────────────┐   │││ │       └───────────────────┘           │
│ │   Ведение сегмента   │   │││ │                                       │
│ │   Единого реестра    │   │││ │                                       │ ┌─────────────────────────────┐
│ │  Экспертов качества  ├───┘││ │                                       │ │<1> Федеральный пакет НСИ    │
│ │  медицинской помощи  │    ││ │                                       │ │формируется в двух вариантах:│
│ └──────────────────────┘    ││ │                                       │ │а) Полный пакет, содержащий  │
│     ┌─────────────┐         ││ │                                       │ │всю НСИ (за исключением      │
│     │ Загрузка и  │         ││ │                                       │ │справочников ТФОМС и Единых  │
│     │использование│<────────┼┘ │                                       │ │реестров);                   │
│     │ в ИС ТФОМС  │         │  │                                       │ │б) Пакет с изменениями,      │
│     └─────────────┘         │  │                                       │ │содержащий только те         │
│                             │  │                                       │ │справочники, по которым      │
├───────────────┐             │  ├───────────┐                           │ │произошли изменения (за      │
│Территориальный│             │  │Федеральный│                           │ │исключением справочников     │
│   фонд ОМС    │             │  │ фонд ОМС  │                           │ │ТФОМС и Единых реестров).    │
└───────────────┴─────────────┘  └───────────┴───────────────────────────┘ └─────────────────────────────┘

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

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

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

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

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

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

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

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

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

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

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

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

NXYYMMVVV.ZIP, где:

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

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

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

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

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

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

- VV - номер версии пакета: 01..99.

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

Федеральный пакет НСИ формируется из классификаторов, приведенных в Таблице 4 настоящего документа (за исключением реестра пунктов выдачи полисов и федеральных справочников).

Актуальные классификаторы, приведенные в пунктах 6 - 11, 18 - 25 и 27 Таблицы 4 настоящего документа включаются в федеральный пакет НСИ в формате XML (кодовая страница Windows-1251). Общероссийские классификаторы, приведенные в пунктах 31 - 35 Таблицы 4, включаются в федеральный пакет НСИ в формате DBF.

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

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) Информационный обмен, осуществляемый с использованием технологии удаленного доступа к РС ЕРЗ, используя web-приложение ТФОМС. СМО осуществляет функции ведения РС ЕРЗ в части собственного сегмента непосредственно в базе данных ТФОМС посредством web-браузера.

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

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

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

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

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

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

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

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

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

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

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

- круглосуточную доступность web-приложения, реализующего возможность доступа к РС ЕРЗ;

- формирование правил и порядка, а также контроль использования СМО web-приложения ТФОМС, реализующего возможность доступа к РС ЕРЗ;

- формирование и контроль соблюдения технических требований по подключению СМО к РС ЕРЗ.

Технология удаленного доступа к Региональному сегменту ЕРЗ должна обеспечить доступ СМО к следующему функционалу:

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

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

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

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

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

Участники информационного обмена обеспечивают защиту передаваемой информации в соответствии с действующим законодательством, причем технология удаленного доступа к РС ЕРЗ должна обеспечивать:

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

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

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

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

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

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, то корневой элемент этого сообщения имеет имя , а сама структура описывается xml-схемой, хранящейся в файле ADT_A01.xsd.

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

Пример.

1903ED97-F5C4-41C5-8035-C6606A9BD7C2

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

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

Пример.

    
      47
      1.2.643.2.40.3.3.1.0
      ISO
    

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

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

Пример.

      
        
          Степанов
        
        Олег
        Михайлович
        L
      

Поле сегмента 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-файла  -
                                  │ первая строка файла
           ...         │ Заголовок пакета
                 [{               │--- Нуль или более сообщений
                              ... │--- Сегменты сообщения
                 }]               │--- Конец сообщения
           ...         │ Сегмент конца пакета
                     │ Последняя строка файла

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    │ Общее подтверждение
                                │
                  ...     │ Заголовок сообщения
                  ...     │ Подтверждение сообщения
                  [{...}] │ Ошибка
                               │

Все подтверждения приема, подтверждения прикладной обработки и ответы на запрос начинаются так же, как описанное выше сообщение общего подтверждения. Если исходное сообщение требует передачи в сообщении подтверждении дополнительных данных, то эти данные включаются в сегменты, которые вставляются после сегмента 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    │ Подтверждение приема запроса
                                │
                  ...     │ Заголовок сообщения
                  ...     │ Подтверждение сообщения
                  [{...}] │ Ошибка ФЛК.
                               │

Сегменты сообщений подтверждения приема описаны в пункте 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

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