Действующий
Сегмент EVN обязателен и не повторяется. Все указанные поля обязательны и включаются в сегмент ровно один раз.
XML- имя | Тип данных | Обяз. поле | Имя поля | Указания по заполнению |
EVN.2 | DTM | Да | Дата и время регистрации события | Дата регистрации события.Значение поля записывается в сокращённом формате, без указания времени (так, как это предусмотрено для полей типа DT): ГГГГ-ММ-ДД. |
EVN.4 | IS | Да | Код причины события | Код причины события (ОИД СК 1.2.643.2.40.5.100.62, таблица 62). |
Любое сообщение, посылаемое в ответ на исходное сообщение, будь то подтверждение приёма, подтверждение прикладной обработки или ответ на запрос, должно включать в себя ряд сведений, которые позволяют связать его с исходным сообщением и указать, успешно ли завершился приём или обработка исходного сообщения. В ответное сообщение также включаются сведения об ошибках, обнаруженных в сообщении, либо возникших при его обработке.
Для большинства исходных сообщений этой информации достаточно в сообщениях подтверждения приёма или прикладной обработки. В связи с этим в стандарт включено сообщение ACK - "Сообщение общего подтверждения", структура которого приведена ниже.
АСК^код-события^АСК | Общее подтверждение |
Заголовок сообщения | |
Подтверждение сообщения | |
[{ | Ошибка |
Все подтверждения приёма, подтверждения прикладной обработки и ответы на запрос начинаются так же, как описанное выше сообщение общего подтверждения. Если исходное сообщение требует передачи в сообщении подтверждении дополнительных данных, то эти данные включаются в сегменты, которые вставляются после сегмента ERR. Туда же включаются дополнительные сегменты, содержащие ответ на запрос в сообщениях, отвечающих на запросы.
Таблица 30 Заполнение сегмента MSH для сообщений подтверждения приёма и сообщений подтверждения прикладной обработки
XML-имя | Тип данных | Обяз. поле | Имя поля | Кмп | Обяз. кмп | Константа | Указания по заполнению | ||||||||||||
MSH.1 | ST | Да | Разделитель полей | I | |||||||||||||||
MSH.2 | ST | Да | Специальные символы кодирования | ^~\& | При xml-кодировании константа должна кодироваться как ^~\& | ||||||||||||||
MSH.3 | HD | Усл | Приложение-отправитель | HD.1 | Да | Кодируемое название (см. примечание в конце таблицы) | |||||||||||||
MSH.4 | HD | Усл | Учреждение-отправитель | HD.1 | Да | Код фонда ОМС из СК 1.2.643.2.40.3.3.1.0, таблица 49 (см. примечание в конце таблицы) | |||||||||||||
HD.2 | Нет | 1.2.643.2.40.3.3.1.0 | |||||||||||||||||
HD.3 | Нет | ISO | |||||||||||||||||
MSH.5 | HD | Усл | Приложение получатель | HD.1 | Да | Кодируемое название (см. примечание в конце таблицы) | |||||||||||||
MSH.6 | HD | Усл | Учреждение-получатель | HD.1 | Да | Код фонда ОМС из СК 1.2.643.2.40.3.3.1.0, таблица 49 (см. примечание в конце таблицы) | |||||||||||||
HD.2 | Нет | 1.2.643.2.40.3.3.1.0 | |||||||||||||||||
HD.3 | Нет | ISO | |||||||||||||||||
MSH.7 | DTM | Да | Дата и время отправки сообщения | Дата, время и часовой пояс, установленные на часах операционной системы на момент готовности сообщения к отправке.Формат - в соответствии с требованиями, предъявляемыми к типу данных DTM (полный формат - см. таблицу 33). | |||||||||||||||
MSH.9 | MSG | Да | Тип сообщения | Для сообщений с ответами на запросы | |||||||||||||||
MSG .1 | Да | RSP | |||||||||||||||||
MSG.2 | Да | Код ответа (таблица Б.27, графа 2) | |||||||||||||||||
MSG.3 | Да | Тип структуры сообщения ответа (таблица Б.27, графа 4) (RSP_ZKn). | |||||||||||||||||
Для сообщений подтверждения (сообщения общего подтверждения - см. п. 6.1.1.5). | |||||||||||||||||||
MSG.1 | Да | ACK | |||||||||||||||||
MSG.2 | Да | Код подтверждаемого события (из исходного сообщения). | |||||||||||||||||
MSG.3 | Да | ACK | |||||||||||||||||
MSH.10 | ST | Да | Идентификатор сообщения | Уникальный идентификатор сообщения | |||||||||||||||
MSH.11 | PT | Да | Тип прикладной обработки | Значение копируется из подтверждаемого сообщения. | |||||||||||||||
MSH.12 | VID | Да | Идентификатор версии стандарта | VID.1 | Да | 2.6 | Номер версии протокола ISO 27931. | ||||||||||||
VID.2 | Нет | CWE.1 | Да | RUS | Код страны, реализующей адаптацию версии | ||||||||||||||
CWE.2 | Нет | Российская Федерация | |||||||||||||||||
CWE.3 | Нет | 1.2.643.2.40.5.0.25.3 | ОИД классификатора стран мира | ||||||||||||||||
VID.3 | Усл. | CWE.1 | Да | Код номера версии адаптированного протокола ФОМС. Отсутствие номера версии воспринимается как эквивалент версии 3.0. | |||||||||||||||
CWE.3 | Нет | 1.2.643.2.40.1.55.1 | ОИД СК номеров версий протокола (таблица 60). |
Сегмент подтверждения сообщения MSA содержит информацию, передаваемую в подтверждениях приёма, прикладной обработки и в ответах на запросы.
XML-имя | Тип данных | Обяз. поле | Имя поля | Указания по заполнению |
MSA.1 | ID | Да | Код подтверждения | Код из СК 1.2.643.2.40.5.100.8 (таблица 57). |
MSA.2 | ST | Да | Идентификатор сообщения | Копируется из MSH.10 исходного (подтверждаемого) сообщения или сообщения запроса. Примечания.1 Если структура файла, который должен содержать пакет сообщений и запросов, ошибочна (не является xml-сообщением или имеет структуру, не соответствующую xml-схеме), то в ответ на такой файл должен быть сформирован пакет, содержащий единственное сообщение подтверждения приёма ACK. Значением MSA.2 в таком случае должно быть имя файла (включающее расширение), перед которым добавляется символ ''*''.2 Если поле MSH.10 сообщения, входящего в пакет, не задано или заполнено пустым значением, то в подтверждении приёма такого сообщения поле MSA.2 заполняется значением, построенным по следующему правилу:''*'' + BHS.11 + ''*'' + <порядковый номер сообщения в пакете>. |
В сегменте ERR передаются комментарии по поводу возникших ошибок, если таковые имели место. Сегмент может использоваться также для передачи информационных сообщений и предупреждений. В таблице 32 даны правила заполнения полей сегмента.
XML-имя | Тип данных | Обяз. поле | Имя поля | Экз. | Кмп | Обяз. кмп | Константа | Указания по заполнению | |||||||||
ERR.2 | ERL | Усл | Позиция ошибки | 0..1 | Позиция ошибки в сообщении. Не указывается только в том случае, когда ошибка относится к пакету сообщений или к сообщению в целом. | ||||||||||||
ERL.1 | Да | Имя сегмента (MSH, PID и т.д.). | |||||||||||||||
ERL.2 | Да | Порядковый номер сегмента в сообщении. Указывается равным нулю в информации об ошибках, связанных с отсутствием обязательных сегментов. | |||||||||||||||
ERL.3 | Нет | Порядковый номер поля в сегменте. | |||||||||||||||
ERL.4 | Нет | Порядковый номер повторения поля. Значение "1" может быть опущено. | |||||||||||||||
ERL.5 | Нет | Номер компонента. | |||||||||||||||
ERL.6 | Нет | Номер субкомпонента. | |||||||||||||||
ERR.3 | CWE | Да | Код ошибки ISO 27931 | 1 | CWE.1 | Да | Код ошибки. | ||||||||||
CWE.2 | Нет | Наименование ошибки. | |||||||||||||||
CWE.3 | Нет | 1.2.643.2.40.5.100.357 | ОИД системы кодирования ошибок ISO 27931(таблица 58). | ||||||||||||||
ERR.4 | ID | Да | Уровень серьёзности | 1 | Код из СК 1.2.643.2.40.5.100.516 (таблица 59). | ||||||||||||
ERR.5 | CWE | Да | Код ошибки приложения | 1 | CWE.1 | Да | Код сообщения*. | ||||||||||
CWE.2 | Да | Текст сообщения | |||||||||||||||
CWE.3 | Нет | 1.2.643.2.40.1.13.8.3 - Ошибка форматно-логического контроля или прикладной обработки ЦС ЕРЗ. | |||||||||||||||
CWE.7 | Нет | Версия системного или прикладного ПО. | |||||||||||||||
ERR.6 | ST | Нет | Параметр ошибки | 0..* | Дополнительные значения, связанные с обнаруженной ошибкой.Каждое значение записывается с использованием форматакод=значениегде код - код из системы кодирования1.2.643.2.40.1.22 (таблица 61),значение - значение, тип и структура которого опре-деляетсякодом, а содержательная интерпретация зависит от поля и определяется при описании соответствующей ошибки. |
Запросы могут иметь параметры, для спецификации которых могут применяться различные способы. В ИС ЕРЗ применяются запросы с простыми параметрами, предполагающие передачу параметров запроса в качестве значений последующих полей специального сегмента QPD, разного для разных запросов. Механизм запроса с простыми параметрами аналогичен механизму вызова хранимой процедуры базы данных.
В ответ на запрос возвращается сообщение, состоящее из сегментов ISO 27931. Это сообщение по своей структуре подобно сообщениям, описанным выше, и содержит те же сегменты.
- Введение, в котором указывается точное имя запроса и словесное описание его назначения, а также тип запроса и тип ответа на запрос.
- Грамматика запроса, определяющая сегменты, которые могут быть переданы отправителем сообщения. Для каждого поля, входящего в указанные сегменты, в профиле запроса точно определяется, как переданное в этом поле значение должно интерпретироваться действующим лицом, которое должно отвечать на запрос.
- Грамматика ответа на запрос, определяющая сегменты, из которых должен быть сконструирован ответ на запрос.
Для получения ответа на запрос прикладная информационная система передаёт в шлюз РС сообщение со структурой, предусмотренной грамматикой выбранного запроса. Шлюз РС производит форматно-логический контроль сообщения и возвращает сообщение ACK с подтверждением приёма. Если исходное сообщение с запросом содержит ошибки ФЛК, то информация об ошибках включается в сообщение подтверждения приёма. Если сообщение не содержит ошибок ФЛК, то оно при необходимости псевдонимизируется и передаётся в ЦС ЕРЗ, который возвращает ответ на запрос в сообщении со структурой, предусмотренной грамматикой ответа на запрос.
Структура подтверждения приёма для всех запросов одинакова и соответствует структуре общего подтверждения:
АСК^код-запроса^АСК | Подтверждение приёма запроса |
Заголовок сообщения | |
Подтверждение сообщения | |
[{ | Ошибка ФЛК. |
Сегменты сообщений подтверждения приёма описаны в пункте 6.1.1.5. Специальных особенностей в их заполнении для прикладного подтверждения сообщений с запросами нет.
Состав простых типов данных сообщений стандарта ISO 27931:2009, используемых в ИС ЕРЗ ОМС, показан на рисунке 6, а их назначение и формат записи значений даны в таблице 33. В столбце "Примечания к реализации" даны дополнительные требования, накладываемые на тип данных в ИС ОМС по сравнению со стандартом ISO.
Тип данных | Название | Требования к формату | Примечания к реализации |
DT | Дата | гггг-мм-ддгггг - год,мм - месяц,дд - число месяца | Допускается указывать только дату целиком: год, месяц и число месяца обязательны. |
ггггтолько год | Допускается указывать только год в полях, представляющих собой дату рождения. | ||
гггг-ммгггг - год, мм - месяц | Допускается указывать год и месяц в полях, представляющих собой дату рождения. | ||
DTM | Дата и время | гггг-мм-ддТчч:мм:СС+-чч:ммгггг-мм-дд - дата,чч:мм:сс - время,+чч:мм или -чч:мм - часовой пояс. | Если описанием поля предусмотрено указание даты и времени (полный формат), то указание времени с точностью до секунд и часового пояса обязательно. |
Полный формат для типа данных DTM должен отвечать стандарту ISO 8601. | |||
гггг-мм-ддгггг - год,мм - месяц,дд - число месяца | Допускается указывать только дату (сокращённый формат) в тех полях, где в указаниях по заполнению имеется прямое указание на это. Указание в таких полях даты и времени в полном формате не считается ошибкой; указанное время игнорируется. | ||
ггггтолько год | Допускается указывать только год в полях, представляющих собой дату рождения. | ||
гггг-ммгггг - год,мм - месяц | Допускается указывать год и месяц в полях, представляющих собой дату рождения. | ||
ID | Табличное значение стандарта ISO 27931:2009 | Значение должно браться из таблицы, включённой в стандарт. Номер таблицы указывается в описании поля, значения предопределены стандартом. | При описании полей типа ID указывается OID системы кодирования, построенной из таблицы стандарта. |
IS | Табличное значение, определяемое реализацией | Значение должно браться из таблицы. Номер таблицы указывается в описании поля, значения в стандарте не определены, их набор и интерпретация зависят от реализации. | При описании полей типа IS указывается OID системы кодирования, используемой для заполнения поля. |
NM | Число | Любой формат записи числового значения, допустимый в xml. | В данной реализации допускаются только натуральные числа и число 0. |
ST | Строка | Любая строка алфавитно-цифровых символов. | На формат значений некоторых полей накладываются дополнительные ограничения, которые даны в описании поля. |
SI | Номер сегмента | Натуральное число. | Служебный тип данных для полей, являющихся счётчиками повторяющихся сегментов в сообщении. |
TX | Текст | Текст в формате base64. | Используется для передачи произвольных вложений. |
Составные типы данных сообщений стандарта ISO 27931:2009, используемые в ИС ОМС, показаны на рисунке 7.
Далее описана структура каждого из составных типов данных. Некоторые компоненты являются обязательными; такие компоненты обязательно должны быть указаны в любом поле данного типа. Необязательные компоненты типа данных могут быть обязательными или условно-обязательными в конкретном поле данного типа, что указано в указаниях по заполнению соответствующего поля.
Кодируемые данные: 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). Эти коды должны означать одно и то же понятие. Такая возможность в ИС ЕРЗ пока не используется/