ВЕРСИЯ 2.24.05

Описание решения

Краткое описание процесса

Процесс проведения лабораторных исследований согласно ГОСТ Р 53022.1-2008 состоит из трех этапов:

1. Преаналитический. К преаналитическому этапу относятся процессы по подготовке заявки на выполнение исследования, передаче заявки и исследуемого материала в КДЛ, подготовке к выполнению исследования. Состоит из двух фаз:
   1. Внелабораторная фаза. Включает в себя:
      1. Формирование направления. Выполняется врачом МО в случае необходимости проведения исследования.
      2. Сбор биоматериала. Осуществляет медицинская сестра процедурного кабинета в соответствии с данными направления.
      3. Формирование заявки. К направлению добавляется необходимая дополнительная информация согласно требованиям лаборатории.
      4. Передача заявки и биоматериала в лабораторию.
   2. Внутрилабораторная фаза. Включает в себя:
      1. Проверка корректности заявки. Выполняется регистратором.
      2. Формирование/изменение заказа (заказ может быть передан в ЛИС из МИС автоматически или внесен в ЛИС сотрудником МО через удаленное рабочее место). Выполняется регистратором/врачом клинической лабораторной диагностики.
2. Аналитический. К аналитическому этапу относится процесс выполнения исследования. Проведение исследования выполняется врачом клинической лабораторной диагностики вручную или с помощью оборудования.
3. Постаналитический. К постаналитическому этапу относятся процессы по утверждению результата, передаче утвержденного результата в МО. Проверка корректности полученных результатов (анализ результатов) выполняется врачом клинической лабораторной диагностики. В случае необходимости производится корректировка заказа и выполнение дополнительных исследований. После подтверждения результаты передаются в МО.

Информационное обеспечение процесса осуществляют: МИС МО (как источник информации о назначении и получатель результатов исследования), ЛИС КДЛ (как получатель информации о назначении и источник результатов исследований) и сервис ДЛИ (как информационная шина, обеспечивающая информационный обмен и как хранилище информации по лабораторным исследованиям).

Описание взаимодействия с сервисом

Сервис ДЛИ предназначен для ведения, хранения, поиска и выдачи сведений по лабораторным исследованиям. Сервис обеспечивает:

1. Централизованный учет заявок на лабораторное исследование.
2. Централизованный учет результатов лабораторных исследований.
3. Учет информации о пациентах, которым назначено лабораторное исследование.
4. Учет информации о медперсонале.
5. Получение заявок на лабораторное исследование и передача их по запросу.
6. Передача статуса заявки по запросу.
7. Получение результатов лабораторных исследований и передача их по запросу.
8. Передача всех результатов лабораторных исследований для МО по запросу.

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

Рисунок 1. Базовая схема информационного взаимодействия

Обмен данными между МИС МО, ЛИС КДЛ и сервиса ДЛИ осуществляется в рамках следующих сценариев:

1. Добавление заявки. Заявка из МИС передается в сервис ДЛИ.
2. Запрос заявки. Заявка не передается в ЛИС автоматически. ЛИС КДЛ запрашивает заявку у сервиса ДЛИ при поступлении исследуемого материала в лабораторию.
3. Добавление результата. Результат передается из ЛИС. В сервис ДЛИ должны передаваться только утвержденные результаты исследований.
4. Запрос статуса заявки. Информация об изменении статуса заявки не передается в МИС автоматически. МИС МО запрашивает статус заявки у сервиса ДЛИ
5. Запрос результата. Результат не передается в МИС автоматически. МИС запрашивает заявку у сервиса ДЛИ.

Описание протокола и запросов приведено в разделе "Описание протокола взаимодействия".

Требования к передаче данных

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

Authorization: N3[пробел][GUID передающей системы]

Авторизационный токен выдается разработчику МИС администратором интеграционной платформы. Авторизационный токен должен соответствовать идентификатору информационной системы, указанному в идентификаторе ресурса, заявки или результата.
Для передачи данных в сервис необходимо передавать в заголовке сообщения заголовок вида content-type: application/json
Текстовая информация, передаваемая в запросах, должна передаваться в кодировке UTF8 (RFC 3629).

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

Все данные типа дата-время (кроме даты рождения пациента) следует передавать в сервис в формате YYYY-MM-DDThh:mm:ss[.SSS]±hh:mm (стандарт ISO8601). Допускается, но не рекомендуется передача данных в формате YYYY-MM-DD и YYYY-MM-DDThh:mm:ss[.SSS]Z. Дату рождения пациента следует передавать в формате YYYY-MM-DD

Ряд ключевых полей (например, DiagnosticReport.issued) сервис всегда возвращает в формате YYYY-MM-DDThh:mm:ss±hh:mm, остальные поля не конвертируются и возвращаются в том формате, в котором были переданы в сервис

Идентификаторы, используемые для связки ресурсов в запросах, и ссылки на существующие ресурсы в БД должны соответствовать требованиям, предъявляемым к GUID (RFC 4122), буквенные символы должны передаваться в нижнем регистре. Идентификаторы для связки ресурсов в запросах должны начинаться с префикса urn:uuid:

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

OID справочников и OID передающей системы, передаваемые в параметрах “system”, должны начинаться с префикса urn:oid:

OID передающей системы, передаваемые в параметрах “display”, должны передаваться без префикса urn:oid:

Передача пустых значений вида parametrname: "" не допускается, за исключением Order.detail.reference в результате без заявки

Ресурсы и бандлы, передаваемые в сервис, должны корректно валидироваться как JSON (RFC 8259) и соответствовать правилам стандарта FHIR по структуре и содержанию.

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

Ответы сервиса

Сервис осуществляет валидацию входных данных при вызовах любых методов. В ответ на запрос сервис возвращает HTTP код состояния и ответ. Основные коды и их значение указаны в таблице ниже.
Если валидация прошла успешно, то сервис возвращает успешный ответ (200, 201), включающий в себя определенные параметры (в зависимости от типа запроса):
если передавался отдельный ресурс, возвращается переданный ресурс, в котором также передаются:

• id — GUID созданного ресурса (присваивается при создании записи в БД, используется для формирования ссылки на ресурс),
• meta — мета данные,
• meta.versionId — версия id ресурса в сервисе ОДЛИ,
• meta.lastUpdated — дата-время последнего обновления ресурса

если передавался ресурс Bundle (заявка, результат, результат без заявки), возвращается Bundle, в котором передаются:

• id — GUID Bundle в сервисе (присваивается при создании записи в БД, используется в служебных целях)
• entry – массив переданных в запросе ресурсов в виде entry, содержащих для каждого ресурса параметры:
  • fullUrl (переданный в запросе параметр fullUrl преобразуется в ссылку на ресурс для дальнейшего запроса его в сервисе - на новый ресурс или ссылка на найденный в БД ресурс),
  • o resource (непосредственно переданный ресурс),
  • o response (status (201-created), location –ссылка на ресурс)

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

Если валидация прошла неуспешно, то сервис возвращает ошибку (400-504), а также параметр issue, содержащий массив с данными по обнаруженным ошибкам:

Использование справочников

Справочники, используемые в сервисе ДЛИ, опубликованы в «Сервисе Терминологии». Описание сервиса Терминологии и правила взаимодействия с ним приведены по ссылке: https://api.n3health.ru/terminologyservice/ .

Для каждого справочника в Настоящем документе указан его OID (объектный идентификатор). Перечень присвоенных корневых OID:

• 1.2.643.5.1.13.2.1 - Корневой OID справочников, размещённых в Федеральном реестре НСИ (http://nsi.rosminzdrav.ru/);
• 1.2.643.2.69.1.1.1 – Корневой OID для справочников подсистемы НСИ Регионального фрагмента.

Передача параметров, использующих значения справочников, не указанных в стандарте FHIR, осуществляется в следующей структуре:

 "coding": [
   {
       "system": "urn:oid:[OID справочника в сервисе Терминологии]",
       "version": "[версия справочника]",
       "code": "[код значения]"
   }
]

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

Особенности использования справочников

• При передаче любого значения с использованием справочника необходимо передавать в том числе используемую версию справочника. Допускается передача значений только по актуальной версии справочника. При валидации значений сервисом значения, передаваемые без указания версии справочника или с указанием неактуальной версии, не проходят валидацию и не принимаются сервисом. Передача значений, отсутствующих в актуальной версии справочника, невозможна.
• При использовании справочника медицинских организаций: в случае, если в справочнике для учреждения зарегистрированы подразделения, необходимо передавать информацию от имени соответствующего подразделения. Передача информации от имени головного учреждения в данном случае не допускается. При передаче заявки на исследование необходимо указывать в заявке (Order.identifier.assigner), данных пациента (Patient.managingOrganization) и случае обслуживания (Encounter.serviceProvider) то учреждение или подразделение (если зарегистрировано в справочнике), где проходит лечение пациент (открыт случай обслуживания и создана заявка). В качестве справочника медицинских организаций (включая подразделения) в сервисе используется справочник 1.2.643.2.69.1.1.1.64

Примеры справочников приводятся на тестовой площадке сервиса Терминология по адресу https://b2b-demo.n3health.ru/nsiui/

Методы сервиса

Сервис ДЛИ поддерживает следующие методы:

1. Передача пациента (POST Patient)
2. Обновление пациента (PUT Patient)
3. Передача врача (POST Practioner)
4. Обновление врача (PUT Practitioner)
5. Передача заявки (POST Bundle заявки)
6. Обновление биоматериала (PUT Specimen)
7. Запрос заявки ($getorder)
8. Запрос заявок ($getorders)
9. Передача результата (POST Bundle результата)
10. Передача результата без заявки (POST Bundle результата без заявки)
11. Запрос статуса ($getstatus)
12. Запрос результата ($getresult)
13. Запрос всех результатов для заданной МО ($getresults)
14. Запрос ресурсов
15. Отмена заявки ($cancelorder)
16. Отмена результата ($cancelresult)
17. Обоснованность назначений ($validity)
18. Передача услуги (POST HealthcareService)
19. Запрос списка услуг для заданной МО

Для корректной работы с сервисом ОДЛИ информационная система также должна поддерживать методы работы с сервисом Терминологии. Минимально необходимо поддерживать метод «Запрос значений справочника». Описание данного метода в данном документе приведено в справочном порядке. С детальным описанием методов работы с сервисом можно ознакомиться по ссылке https://api.n3health.ru/terminologyservice/

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

Параметр «Кратность» означает количество возможных значений реквизита:

0..1 - параметр необязательный, максимальное количество экземпляров один;
0..* – параметр необязательный, максимальное количество экземпляров не ограничено;
1..1 – параметр обязательный, экземпляр один;
1..2 – параметр обязательный, экземпляр один или два;
1..* – параметр обязательный, максимальное количество экземпляров не ограничено

Обмен данными о пациенте

При информационном взаимодействии могут осуществляться следующие операции:

1. Добавление пациента в сервис ДЛИ. Осуществляется передача данных о пациенте, направленном на лабораторное исследование.
2. Обновление данных. Обновление базовой информации о пациенте (ФИО, адрес, паспорт, полис).
3. Передача данных о пациенте из сервиса ДЛИ по запросу. МИС МО или ЛИС КДЛ может запрашивать актуальную информацию о пациенте.

Процесс обмена данными о пациенте приведен на [Рисунок 2].

 

Передача пациента (POST Patient)

Для регистрации пациента в сервисе ДЛИ используется POST-запрос ресурса Patient. В качестве адреса указывается URL в формате [base]/Patient?_format=json. В ответе сервис возвращает json с созданным пациентом и его идентификатором в сервисе ДЛИ.

Уникальность пациента проверяется по совокупности параметров identifier.value (идентификатор пациента в МИС), identifier.assigner.display (OID передающей системы), managingOrganization (передающая организация). Многократная передача одного и того же пациента из одной и той же МИС с разными набором ключевых параметров категорически запрещена. Передача разных пациентов с одним и тем же набором ключевых параметров категорически запрещена.

В случае, если пациент передается в сервис впервые – в сервисе будет создан соответствующий ресурс.

В случае, если пациент уже зарегистрирован в сервисе – данные пациента в сервисе будут обновлены. Правила обновления приведены в разделе «Особенности обновления данных пациента».

Описание параметров

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

Параметры ресурса Patient

Особенности передачи данных пациента

Для корректной работы федеральных сервисов СЭМД, РЭМД при передаче пациента обязательно должен передаваться СНИЛС
Для корректной работы смежных сервисов N3 (MPI, Портал врача, Личный кабинет пациента) при передаче пациента должны передаваться номер полиса и СНИЛС
СНИЛС и номер полиса пациента могут проверяться сервисом ОДЛИ на совпадение контрольной суммы.
При передаче данных анонимного пациента к имени пациента необходимо добавлять параметр name.use == anonymous. Для анонимного пациента запрещена передача персонализированных данных (адрес, номер полиса, паспорта, СНИЛС). Параметры name.given, name.family должны содержать произвольные значения, например "Анонимный"

При передаче данных анонимных пациентов следует в ресурсе Patient передавать параметр name.use = “anonimous”, не передавать никакие идентификаторы, кроме идентификатора в МИС/ЛИС, не передавать адрес пациента.

При передаче заведомо некорректных данных пациента (неопознанные пациенты, лица БОМЖ и др.) к имени пациента необходимо добавлять параметр name.use == temp. Параметры name.given, name.family должны содержать произвольные значения, например "Неизвестно". В случае появления информации о корректных данных необходимо обновить данные пациента в сервисе методом PUT Patient, исключив указанный параметр.

При передаче заведомо некорректных данных новорожденного пациента, для которого не определено имя, к имени пациента необходимо добавлять параметр name.use == temp. Фамилия (name.family) должна быть передана корректно, имя (name.given) должно содержать значение "Новорожденный", отчество может не передаваться. В случае появления информации о корректных данных необходимо обновить данные пациента в сервисе методом PUT Patient, исключив указанный параметр.

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

Для корректной передачи данных в случаях, когда лечение производится за счет средств ОМС по полису представителя, необходимо передавать данные следующим образом:
- представитель пациента передается как отдельный ресурс Patient, для него передается его полис
- для пациента в параметре Patient.link.other указывается ссылка на ресурс Patient, описывающий представителя
- в заявке на исследование указывается источник финансирования «Оплата по полису представителя»

При добавлении нового пациента в качестве адреса указывается URL в формате [base]/Patient?_format=json. В ответе сервис возвращает json с созданным пациентом и его идентификатором в сервисе ДЛИ.

Пример запроса приведен в разделе "Примеры запросов" .

Обновление пациента (PUT Patient)

В подсистеме ДЛИ должна быть возможность обновить информацию о пациенте. При обновлении данных должна передаваться полная информация о пациенте, т.е. для корректной работы МИС должна сначала запросить ресурс Patient (операция GET), а потом передать его со всеми параметрами, в том числе и неизменившимися (операция PUT). Обновление ресурса разрешено только отправителям данного ресурса. Методом PUT нельзя менять ключевые параметры, определяющие уникальность ресурса - идентификатор в МИС, организацию, OID передающей системы.
При обновлении пациента в качестве адреса указывается URL в формате [base]/Patient/[GUID]?_format=json. GUID пациента в URL должен соответствовать id, указанному в запросе. В ответе сервис возвращает json с обновленным пациентом и его идентификатором в сервисе ДЛИ.

Описание параметров

Параметры ресурса Patient приведены в таблице выше.

Особенности обновления данных пациента

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

• Обновление данных пациента возможно, если name.use в данных пациента в сервисе temp, official или отсутствует.
• Если в данных пациента в сервисе name.use = temp и возраст пациента более 30 дней (от момента рождения), за один запрос можно изменить ФИО и ДР. name.use разрешено изменить на official (должно быть изменено c temp на official в случае окончательного уточнения данных пациента).\
• Если в данных пациента в сервисе name.use = temp, official или отсутствует и возраст пациента менее 30 дней (от момента рождения), за один запрос можно изменить ФИО или ДР. name.use разрешено изменить на official (должно быть изменено с temp на official в случае окончательного уточнения данных пациента).
• Если в данных пациента в сервисе name.use = official или отсутствует и возраст пациента более 30 дней (от момента рождения), за один запрос можно изменить фамилию или имя или отчество или дату рождения.
• Допустимые изменения name.use:
  • • o пусто или temp можно изменить на official
    • o anonymous и official на любой другой изменять ЗАПРЕЩЕНО.

Пример запроса

МИС должна запросить ресурс Patient (операция GET)

При обновлении пациента в качестве адреса указывается URL в формате [base]/Patient/[GUID]?_format=json. GUID пациента в URL должен соответствовать id, указанному в запросе. При обновлении данных необходимо передавать полностью ресурс Patient, а не только измененные значения.

Пример запроса приведен в разделе "Примеры запросов".

Передача врача (POST Practitioner)

Для регистрации врача в сервисе ДЛИ используется POST-запрос ресурса Practitioner. В качестве адреса указывается URL в формате [base]/Practitioner?_format=json. В ответе сервис возвращает json с созданным врачом и его идентификатором в сервисе ДЛИ.

Уникальность врача проверяется по совокупности параметров identifier.value (идентификатор врача в МИС), identifier.assigner.display (OID передающей системы), practitionerRole.managingOrganization (передающая организация), practitionerRole.specialty (код специальности) и practitionerRole.role (код должности). Многократная передача одного и того же врача из одной и той же МИС с разными набором ключевых параметров категорически запрещена. Передача разных врачей с одним и тем же набором ключевых параметров категорически запрещена.

В случае, если врач передается в сервис впервые – в сервисе будет создан соответствующий ресурс. В случае, если врач уже зарегистрирован в сервисе – данные врача в сервисе будут обновлены.

Описание параметров

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

Таблица 3. Параметры Practitioner

Для корректной работы федеральных сервисов СЭМД, РЭМД при передаче врача должен передаваться СНИЛС. СНИЛС врача, должность врача, МО должны совпадать с соответствующими данными работника в ФРМР.
СНИЛС врача может проверяться сервисом ОДЛИ на совпадение контрольной суммы.

Пример запроса приведен в разделе "Примеры запросов".

Обновление врача (PUT Practitioner)

В подсистеме ДЛИ должна быть возможность обновить информацию о враче. При обновлении данных должна передаваться полная информация о враче, т.е. для более корректной работы МИС должна запросить ресурс Practitioner (операция GET), а потом передать его со всеми параметрами, в том числе и неизменившимися (операция PUT). Обновление ресурса разрешено только отправителям данного ресурса. Методом PUT нельзя менять ключевые параметры - должность, специальность, идентификатор в МИС, организацию.

При обновлении врача в качестве адреса указывается URL в формате [base]/Practitioner/[GUID]?_format=json. В ответе сервис возвращает json с обновленным врачом и его идентификатором в сервисе ДЛИ.

Описание параметров

Параметры ресурса Practitioner приведены в таблице выше.

Пример запроса приведен в разделе "Примеры запросов".

Передача заявки (POST Bundle заявки)

Для передачи заявки должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:

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

Уникальность заявки проверяется по совокупности параметров ресурса Order identifier.system (OID передающей системы), identifier.value (идентификатор заявки в МИС), identifier.assigner (передающая организация). Многократная передача одной и той же заявки (с одним и тем же набором ключевых параметров) запрещена (допускается после отмены заявки).

Структура Bundle

Bundle используется для передачи набора ресурсов. Для каждого из ресурсов Bundle должна указываться операция (POST). Перечень ресурсов и их описание представлено в таблице ниже.

 Описание ресурсов, входящих в состав Bundle

Схема структуры Bundle приведена на рисунке ниже

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

Обязательность ресурсов внутри Bundle и допустимые операции

Структура запроса Bundle заявки

При добавлении заявки в качестве адреса указывается URL в формате [base]?_format=json. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ДЛИ.

Json-запрос для передачи заявки содержит следующие компоненты:

• • Указание, что в запросе передается Bundle,
  • Метаинформация (meta.profile — ссылка на ресурс StructureDefinition. Необходимо всегда указывать ссылку на ресурс StructureDefinition с идентификатором cd45a667-bde0-490f-b602-8d780acf4aa2. Ресурс StructureDefinition описывает структуру JSON-запроса — набор определений элементов данных, и связанные с ними правила использования),
  • Тип Bundle,
  • Данные о передаваемых ресурсах:

• • • fullUrl ресурса,
    • Сам ресурс,
    • Операция над этим ресурсом.

Общее описание структуры запроса приведено на рисунке ниже.

Структура json-запроса для передачи Bundle заявки

Пример базовой структуры json-запроса для передачи заявки приведен в разделе "Примеры запросов".

Описание ресурсов, входящих в состав Bundle

Order

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

Таблица 6. Параметры Order

* Все требования к передаче приложений к направлению полностью совпадают с требованиями по передаче приложений к результатам и детально описаны в разделах «Передача результата. DiagnosticReport», «Передача результата. Binary». Необходимо пользоваться описанием из указанных разделов.

Пример фрагмента Bundle для Order приведен в разделе "Примеры запросов".

DiagnosticOrder

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

Параметры DiagnosticOrder

Пример фрагмента Bundle для DiagnosticOrder приведен в разделе "Примеры запросов".

Specimen

Ресурс Specimen предназначен для передачи информации о забранном биоматериале. Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Более детальная информация по правилам передачи биоматериала приведена в разделе «Передача информации о биоматериале»

Таблица 8. Параметры Specimen

Encounter

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

Параметры Encounter

Пример фрагмента Bundle для Encounter приведен в разделе "Примеры запросов".

Condition

Ресурс Condition предназначен для передачи информации о состоянии пациента. Содержание ресурса Condition определяется по значению параметра category:

• Для диагноза category = diagnosis.
• Для даты начала последней менструации category = symptom
• Для признака менопаузы category = finding.

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

Параметры Condition

Пример фрагмента Bundle для Condition приведен в разделе "Примеры запросов".

Observation

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

Параметры Observation

Содержание ресурса Observation определяется по значению параметров system и code.
Список основных используемых параметров, передаваемых по справочнику 1.2.643.2.69.1.1.1.37, и их описание приведены в таблице ниже.

Параметры Observation

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

Пример фрагмента Bundle для Observation приведен в разделе "Примеры запросов".

Practitioner

Ресурс Practitioner предназначен для передачи информации о враче. В этом ресурсе указывается:

• Врач, сделавший назначение;
• Врач-автор заявки.

В случае, если врач передается в сервис впервые – в сервисе будет создан соответствующий ресурс. В случае, если врач уже зарегистрирован в сервисе – данные врача в сервисе будут обновлены.

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

Patient

Ресурс Patient предназначен для передачи информации о пациенте.
В случае, если пациент передается в сервис впервые – в сервисе будет создан соответствующий ресурс. Перечень параметров и их описание представлены в разделе «Передача пациента».

В случае, если пациент уже зарегистрирован в сервисе – данные пациента в сервисе будут обновлены. Правила обновления приведены в разделе «Особенности обновления данных пациента».

Запрос заявки ($getorder)

Получение информации о конкретной заявке может осуществляться двумя способами: с помощью GET запроса ресурса Order по GUID или с помощью дополнительной операции (Custom Operation) getorder (POST).
При поиске заявки по второму способу используется POST запрос, в качестве адреса указывается URL в формате [base]/$getorder?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.
Внутри полученных с помощью данного запроса массива ресурсов имеются ссылки на другие ресурсы. Информация по ним запрашивается с помощью функционала получения ресурса по GUID (GET с указанием ссылки на запрашиваемый ресурс), для чего запрашивающая система должна выполнить соответствующие запросы. Структура этих запросов описана в разделе «Запрос ресурсов»

Описание параметров

Входные и выходные параметры операции getorder приведены в таблице ниже.

Параметры операции $getorder

Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов Order, удовлетворяющих условиям запроса.
* Штрихкод может содержать только цифры и буквы латинского алфавита. Не может содержать пробелы и любые другие символы. Допускается перечисление нескольких штрихкодов в поле Barcode через запятую – в этом случае поиск будет вестись по всем перечисленным штрихкодам.
Под датой в данном методе подразумевается дата записи заявки в БД ДЛИ (служебное поле).

Пример запроса

При поиске заявки в качестве адреса указывается URL в формате [base]/$getorder?_format=json. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.

Пример запроса приведен в разделе "Примеры запросов".

Запрос заявок ($getorders)

Получение информации о массиве заявок осуществляется с помощью дополнительной операции (Custom Operation) getorders (POST).

При поиске заявки используется POST запрос, в качестве адреса указывается URL в формате [base]/$getorders?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.

Внутри полученных с помощью данного запроса массива ресурсов имеются ссылки на другие ресурсы. Информация по ним запрашивается с помощью функционала получения ресурса по GUID (GET с указанием ссылки на запрашиваемый ресурс), для чего запрашивающая система должна выполнить соответствующие запросы. Структура этих запросов описана в разделе «Запрос ресурсов»

Описание параметров

Входные и выходные параметры операции getorders приведены в таблице ниже.

Параметры операции $getorders

Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов Order, удовлетворяющих условиям запроса.
Под датой в данном методе подразумевается дата записи заявки в БД ДЛИ (служебное поле).

Пример запроса

При поиске заявки в качестве адреса указывается URL в формате [base]/$getorders?_format=json. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.

Пример запроса приведен в разделе "Примеры запросов".

Передача результата (POST Bundle результата)

Для передачи результата должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:

• Ответ на заявку.
• Общие сведения о результате (идентификатор, дата и т.п.).
• Информация о враче, выполнившем исследование и утвердившем результат.
• Результаты тестов
• Сведения об использованном оборудовании
• Печатная форма протокола исследования в формате PDF и/или xml (CDA)

Уникальность результата проверяется по совокупности параметров ресурса OrderResponse identifier.system (OID передающей системы), identifier.value (идентификатор заявки в МИС), who (передающая организация). Многократная передача одного и того же результата (с одним и тем же набором ключевых параметров) запрещена (допускается после отмены результата).

Структура Bundle

Bundle используется для передачи набора ресурсов. Для каждого из ресурсов Bundle должна указываться операция (POST, PUT). Перечень ресурсов и их описание представлено в таблице ниже.

Описание ресурсов, входящих в состав Bundle

Структура Bundle

Допустимые операции над ресурсами Bundle

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

Обязательность ресурсов внутри Bundle и допустимые операции

Структура запроса Bundle результата

При добавлении результата в качестве адреса указывается URL в формате [base]?_format=json. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ДЛИ.

Json-запрос для передачи результата содержит следующие компоненты:

• Указание, что в запросе передается Bundle,
• Метаинформация,
• Тип Bundle,
• Данные о передаваемых ресурсах:
  • fullUrl ресурса,
  • Сам ресурс,
  • Операция над этим ресурсом.

Общее описание структуры запроса приведено на рисунке ниже.

Структура json-запроса для передачи Bundle результата

Пример базовой структуры json-запроса для передачи результата приведен в разделе "Примеры запросов".

Описание ресурсов, входящих в состав Bundle

OrderResponse

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

Параметры OrderResponse

DiagnosticReport

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

Параметры DiagnosticReport

* В зависимости от региональных настроек могут использоваться региональный (1.2.643.2.69.1.1.1.2) или федеральный (1.2.643.5.1.13.13.11.1005) справочники МКБ-10, а также федеральные справочники МКБ-О 1.2.643.5.1.13.13.11.1486 и 1.2.643.5.1.13.13.11.1487 для передачи онкологических диагнозов
Общие правила передачи результатов исследований
- если результат по заявке передается полностью, или отправляется последняя часть со статусом «completed», то для каждого DiagnosticOrder в заявке должен быть передан DiagnosticReport в ответе. Передача результата со статусом «completed» в том случае, если для одного или нескольких DiagnosticOrder в заявке не передается DiagnosticReport в ответе, недопустима.
- если ответ по заявке (DiagnosticReport) передается со статусом «final» или «cancelled», то код услуги в DiagnosticReport должен равняться коду услуги в DiagnosticOrder
- если ответ по заявке передается со статусом «corrected», код услуги в DiagnosticReport может отличаться от кода услуги в DiagnosticOrder (в случае, если произошла обоснованная замена услуги результата. Ответственность за такую замену несет целевая МО/КДЛ)
- передача одинаковых DiagnosticReport в рамках одного OrderResponse (с одинаковым кодом выполненной услуги, кодом теста в Observation) не допускается.

Пример фрагмента Bundle для DiagnosticReport приведен в разделе "Примеры запросов".

Observation

В Bundle для передачи результата ресурс Observation предназначен для передачи результата теста (в Bundle для передачи заявки этот же ресурс используется для указания других параметров). Содержание ресурса Observation определяется по значению параметра code. Также по данному параметру определяется обязательность заполнения полей valueQuantity, valueString
Список видов Observation и способов их использования приведены в таблице ниже.

Виды Observation

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

Параметры Observation

Результаты клинических исследований, а также результаты микробиологических и гистологических исследований (если применимо) могут быть переданы в виде текстового или числового значения. При передаче результатов теста следует использовать следующие правила:
- если в сервис передается значение теста, для которого в справочнике тестов указана единица измерения – то значение должно передаваться только как число (valueQuantity), референтные значения должны передаваться только как число (referenceRange.low и/или referenceRange.high). Если для данного теста референтное значение отсутствует или неприменимо, допускается передача референтного значения как текст (referenceRange.text), но при этом значение может быть только «нет». Результат теста и референтные значения должны передаваться в одних и тех же единицах измерения (валидация не отключаемая)
- если в сервис передается значение теста, для которого в справочнике тестов не указана единица измерения – то значение должно передаваться только как текст (valueString), референтные значения должны передаваться только как текст (referenceRange.text). Если для данного теста референтное значение отсутствует или неприменимо, необходимо передавать референтное значение тоже как текст (referenceRange.text), но при этом значение должно быть «нет».
- передача одинаковых DiagnosticReport в рамках одного OrderResponse (с одинаковым кодом выполненной услуги и передача одинаковых Observation в рамках одного DiagnosticReport (с одинаковым кодом теста в Observation) не допускается.
Передача информации о соответствии или несоответствии результата конкретного теста норме осуществляется путем передачи значения в поле interpretation. Перечень рекомендованных значений для количественных тестов: H (Повышенный), L (Пониженный), N (Нормальный (в пределах референсного диапазона)), для качественных тестов DET (Выявлено) ND (Не выявлено) E (Сомнительно) IND (Не определено). Допускается использование других значений кодов интерпретации, соответствующих результату данного теста. Передача кода интерпретации константой категорически запрещена!

Примеры базовых структур json-запроса для передачи результата по микробиологии приведены в разделе "Примеры запросов".

Practitioner

Ресурс Practitioner предназначен для передачи информации о враче. В этом ресурсе указывается:

• Врач, выполнивший тест;
• Врач, утвердивший результат тестов услуги.

Пример фрагмента Bundle для Practitioner приведен в разделе "Примеры запросов".

Device

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

Параметры Device

Примеры фрагмента Bundle для Device приведен в разделе "Примеры запросов".

Binary

В Bundle для передачи протокола исследования в формате PDF, CDA документов и УКЭП для них используется ресурс Binary.
В качестве PDF-документа должен передаваться пригодный для просмотра и печати протокол лабораторного исследования, соответствующий передаваемым результатам. Передача пустого PDF документа или документа, не содержащего требуемых данных, не допускается. Текстовая часть должна включаться в документ формата PDF/A-1 в виде текстовых данных. Вставка текста в документ в виде изображения не допускается.
Файл документа в электронном виде должен иметь формат PDF/A-1, соответствующий международному стандарту ISO 19005-1:2005 «Управление документацией. Формат файлов электронных документов для долгосрочного сохранения. Часть 1: Использование формата PDF 1.4 (PDF/A-1)» - Document management - Electronic document file format for long-term preservation - Part 1: Use of PDF 1.4 (PDF/A-1) [5]. В качестве подписи должна передаваться УКЭП в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012
Дополнительно может передаваться XML-документ, пригодный для передачи в федеральные сервисы СЭМД, РЭМД, ВИМИС. Документ должен соответствовать:
- передаваемым в результате структурированным данным

- требованиям к соответствующему документу, размещенным на портале ЕГИСЗ
Тип и версия передаваемого документа должны быть указаны в параметре Binary.meta.tag
Для выгрузки в федеральный сервис РЭМД PDF и XML документы должны быть подписаны. В качестве подписи должна передаваться УКЭП в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012. Детальные требования к УКЭП размещены на портале ЕГИСЗ
Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.

Параметры Binary

Типы Binary

Передача результата без заявки (POST Bundle без заявки)

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

Для передачи результата без заявки должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:

• Общие сведения о заявке (отправитель, получатель)
• Ответ на заявку.
• Общие сведения о результате (идентификатор, дата и т.п.).
• Информация о пациенте
• Информация о враче, выполнившем исследование и утвердившем результат.
• Результаты тестов
• Сведения об использованном оборудовании
• Печатная форма протокола исследования в формате PDF/xml

Отличие от аналогичного Bundle результата следующие:

• В Bundle включены ресурсы Order, Specimen, Patient;
• Вместо внешних ссылок на ресурсы Bundle заявки используется внутренние ссылки на ресурсы Order, Specimen, Patient
• В ресурсе DiagnosticReport передается ссылка на ресурсы Specimen, входящие в данный Bundle

Уникальность результата проверяется по совокупности параметров ресурса OrderResponse identifier.system (OID передающей системы), identifier.value (идентификатор заявки в МИС), who (передающая организация). Многократная передача одного и того же результата (с одним и тем же набором ключевых параметров) запрещена (допускается после отмены результата).

Структура Bundle

Bundle используется для передачи набора ресурсов. Для каждого из ресурсов Bundle должна указываться операция (POST, PUT). Перечень ресурсов и их описание представлены в таблице ниже.

Описание ресурсов, входящих в состав Bundle

Схема структуры Bundle приведена на рисунке ниже.

Структура Bundle

Допустимые операции над ресурсами Bundle

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

Обязательность ресурсов внутри Bundle и допустимые операции

Структура запроса Bundle результата без заявки

При добавлении результата в качестве адреса указывается URL в формате [base]/?_format=json. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ДЛИ.
Json-запрос для передачи результата содержит следующие компоненты:

• • Указание, что в запросе передается Bundle,
  • Метаинформация (meta.profile — ссылка на ресурс StructureDefinition. Необходимо всегда указывать ссылку на ресурс StructureDefinition с идентификатором 21f687dd-0b3b-4a7b-af8f-04be625c0201. Ресурс StructureDefinition описывает структуру JSON-запроса — набор определений элементов данных, и связанные с ними правила использования),
  • Тип Bundle,
  • Данные о передаваемых ресурсах:

• • • fullUrl ресурса,
    • Сам ресурс,
    • Операция над этим ресурсом.

Общее описание структуры запроса приведено на рисунке ниже.

Структура json-запроса для передачи Bundle результата

Примеры базовой структуры json-запроса для передачи результата без заявки приведены в разделе "Примеры запросов".

Описание дополнительных ресурсов, входящих в состав Bundle результата без заявки

Order

Ресурс Order предназначен для передачи информации о ЛПУ откуда поступил биоматериал и в какую лабораторию направлен на исследование. С реальной заявкой на исследование никак не связан, нужен для соблюдения стандарта FHIR. Также при получении ресурса Order сервисом автоматически формируется и возвращается идентификатор заявки (необходимо для соблюдения требований стандарта FHIR). Идентификатор формируется по следующим правилам: System = orderResponse.Identifier.System, Value = orderResponse.Identifier.Value, Assigner = Order.Source. Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.

Параметры Order

Пример фрагмента Bundle для Order приведен в разделе "Примеры запросов".

Запрос статуса ($getstatus)

Получение информации о статусе конкретной заявки осуществляется с помощью дополнительной операции (Custom Operation) getstatus (POST).
При запросе статуса заявки используется POST запрос, в качестве адреса указывается URL в формате [base]/$getstatus?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json со статусом данной заявки.

Описание параметров

Входные и выходные параметры операции getstatus приведены в таблице ниже.

Параметры операции

Выходным параметром является JSON вида {"resourceType":"Parameters","parameter":[{"name":"Status","valueString":"Х"}]}, где Х – это статус ресурса Order, удовлетворяющего условиям запроса.

Пример запроса

При поиске результатов выполненных исследований в качестве адреса указывается URL в формате [base]/$getstatus?_format=json. В ответе сервис возвращает json со значением статуса заявки, найденной в сервисе ДЛИ.

Пример запроса приведен в разделе "Примеры запросов".

Запрос результата ($getresult)

Получение информации о результате конкретного выполненного исследования может осуществляться двумя способами: с помощью запроса ресурса OrderResponse или с помощью дополнительной операции (Custom Operation) getresult (POST).
При запросе результатов выполненных исследований по второму способу используется POST запрос, в качестве адреса указывается URL в формате [base]/$getresult?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с массивом OrderResponse, найденных в сервисе ДЛИ.
Внутри полученных с помощью данного запроса ресурсов имеются ссылки на другие ресурсы. Информация по ним запрашивается с помощью функционала получения ресурса по GUID (GET с указанием ссылки на запрашиваемый ресурс), для чего запрашивающая система должна выполнить соответствующие запросы. Структура этих запросов описана в разделе «Запрос ресурсов»

Описание параметров

Входные и выходные параметры операции getresult приведены в таблице ниже.

Параметры операции $getresult

* Указывается GUID подразделения организации, фактически выполнившей исследование и указанное в результате. Может отличаться от GUID, указанного в параметре Order.target заявки. GUID подразделений, фактически выполняющих исследование, необходимо уточнять в информационной системе, передающей результаты в сервис. Если таких подразделений несколько, они могут передаваться в одном запросе в строке, разделенной запятыми (не более 10 GUID)
Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов OrderResponse, удовлетворяющих условиям запроса.

Пример запроса

При поиске результатов выполненных исследований в качестве адреса указывается URL в формате [base]/$getresult?_format=json. В ответе сервис возвращает json с массивом OrderResponse, найденных в сервисе ДЛИ.

Пример запроса приведен в разделе "Примеры запросов".

Запрос всех результатов для заданной МО ($getresults)

Получение информации о массиве результатов осуществляется с помощью дополнительной операции (Custom Operation) getresults.
При запросе массива заявок используется POST запрос, в качестве адреса указывается URL в формате [base]/$getresults?_format=json в теле запроса передаются параметры запроса. В ответе сервис возвращает json с массивом OrderResponse, найденных в сервисе ДЛИ.
Внутри полученных с помощью данного запроса ресурсов имеются ссылки на другие ресурсы. Информация по ним запрашивается с помощью функционала получения ресурса по GUID (GET с указанием ссылки на запрашиваемый ресурс), для чего запрашивающая система должна выполнить соответствующие запросы. Структура этих запросов описана в разделе «Запрос ресурсов»

Описание параметров

Входные и выходные параметры операции getresults приведены в таблице ниже.

Таблица 27. Параметры операции $getresults

* Указывается GUID подразделения организации, фактически выполнившей исследование и указанное в результате. Может отличаться от GUID, указанного в параметре Order.target заявки. GUID подразделений, фактически выполняющих исследование, необходимо уточнять в информационной системе, передающей результаты в сервис. Если таких подразделений несколько, они могут передаваться в одном запросе в строке, разделенной запятыми (не более 10 GUID)
Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов OrderResponse, удовлетворяющих условиям запроса.
Под датой в данном методе подразумевается дата записи результата в БД ДЛИ (служебное поле).

Пример запроса

При поиске результатов выполненных исследований в качестве адреса указывается URL в формате [base]/$getresults?_format=json. В ответе сервис возвращает json с массивом OrderResponse, найденных в сервисе ДЛИ.

Пример запроса приведен в разделе "Примеры запросов".

Запрос ресурсов

Любой ресурс можно запросить с помощью GET-запроса. В качестве адреса должен быть указан URL в формате [base]/[Наименование ресурса]/[идентификатор ресурса в сервисе ДЛИ]?_format=json. Например,

[base]/DiagnosticReport/9bacab3f-63d3-4a3a-8d10-599b5b598b39?_format=json

Отмена заявки ($cancelorder)

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

Отмена конкретной заявки осуществляется с помощью дополнительной операции (Custom Operation) cancelorder (POST).

При отмене заявки используется POST запрос, в качестве адреса указывается URL в формате [base]/$ cancelorder?_format=json в теле запроса передаются параметры запроса. В ответе сервис возвращает json со статусом данной заявки cancelled.
При отмене заявки сервис ОДЛИ помечает заявку и все входящие в нее ресурсы как отмененные. Такая заявка более не может быть запрошена в сервисе методами запроса заявок. По такой заявке не возвращается статус. Возможна повторная передача заявки с таким же OrderMISID.

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

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

- отмененная заявка не запрашивается из сервиса методами $getresult, $getresults, но может быть запрошена стандартными методами FHIR search (при этом все объекты заявки будут иметь статус «отменен», ЛИС должна корректно обрабатывать данную ситуацию)

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

Описание параметров

Входные параметры операции cancelorder приведены в таблице ниже.

Параметры операции $cancelorder

Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов, отмененных в ходе запроса. В параметре "name" передается ссылка на ресурс, в параметре "valueString" статус операции: "True", означающий успешную отмену ресурса.

Пример файла запроса можно получить через службу технической поддержки. Метод может быть неактивен в учреждении.

Отмена результата ($cancelresult)

В ряде медицинских учреждений необходима возможность аннулирования результатов, переданных в сервис.
Отмена конкретного результата осуществляется с помощью дополнительной операции (Custom Operation) cancelresult (POST).
При отмене результата используется POST запрос, в качестве адреса указывается URL в формате [base]/$ cancelresult?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json со статусом данной результата cancelled.
При отмене результата сервис ОДЛИ помечает результат и все входящие в него ресурсы как отмененные. Такой результат более не может быть запрошен в сервисе методами запроса результата. Возможна повторная передача результата с таким же OrderMISID.
Ограничения метода:
- сервис ОДЛИ пассивный, т.е. он только получает информацию от участников информационного взаимодействия. Сервис ОДЛИ не может информировать МИС о том, что результат отменен. Информирование контрагента в таком случае должно решаться иными способами.
- при отмене результата он не может быть отозван из федеральных сервисов (СЭМД, РЭМД и др.)
- отмена возможна только отправителем результата. Авторизационный токен, используемый при отмене, должен совпадать с токеном, использованным при передаче.
В случае, если результат передавался частями (accepted и completed), его часть необходимо отменить и передать корректный результат, действуют особые правила отмены и повторной передачи результата.

1. В случае, если отменяется одна из первых частей результата (accepted), то отменять надо ее и последнюю часть (completed), чтобы снять с результата отметку «выполнено»
2. При передаче результата взамен отмененного следует передавать DiagnosticReport только на те DiagnosticOrder, по которым ранее были отменены DiagnosticReport.
3. При передаче результата взамен отмененного последним следует передать OrderResponse в статусе completed (для того, чтобы вернуть на результат отметку «выполнено»). Передача исправленного результата частями (accepted и completed) допускается.

Описание параметров

Входные параметры операции cancelresult приведены в таблице ниже.

Параметры операции $cancelresult

Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов, отмененных в ходе запроса. В параметре "name" передается ссылка на ресурс, в параметре "valueString" статус операции: "True", означающий успешную отмену ресурса.

Пример файла запроса можно получить через службу технической поддержки. Метод может быть неактивен в учреждении.

Обоснованность назначений ($validity)

Для некоторых лабораторных исследований, как правило – дорогостоящих, есть необходимость проверки – можно ли их назначать. При этом существуют три основных критерия, по которым определяется возможность назначения исследования
• наличие ранее выполненных исследований в пределах срока годности или срока интерпретации (Пример: A09.05.202.001 Определение онкомаркера СА 125 иммунохемилюминесцентным методом нет смысла брать чаще чем раз в месяц)
• должность врача, назначающего исследование (Пример: A09.05.132.004 Определение фолликулостимулирующего гормона методом ИХЛ у женщин назначает гинеколог, эндокринолог)
• диагноз пациента, которому назначается исследование (Пример: A25.30.175 Определение антител класса G к хеликобактер пилори (полуколичественный) назначается при диагнозе K25.7 Язва желудка хроническая без кровотечения и прободения)
В сервисе реализован метод $validity, при помощи которого направляющая МИС может получить ответ на вопрос – является ли данное назначение обоснованным, нет ли нарушений одного из критериев.
Подготовка справочника
Для работы метода в справочник «Код услуги заявки» должны быть добавлены три атрибута. В случае необходимости указания нескольких значений – они указываются через точку с запятой. Указание диапазонов не допускается.

Настройка ограничений в справочнике

Ограничение метода: ЕСЛИ для услуги настраивается ограничение, ТО параметр Validity_Date ДОЛЖЕН быть заполнен обязательно.
Получение информации о возможности заказа лабораторного исследования (контроль обоснованности) может осуществляться с помощью дополнительной операции (Custom Operation) validity (POST).

При контроле обоснованности используется POST запрос, в качестве адреса указывается URL в формате [base]/$ validity?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с ответом.

Описание параметров

Входные параметры операции validity приведены в таблице ниже.

Параметры операции $validity

Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов, описывающих результаты проверки. В проверке участвуют те параметры, которые были переданы. Ответ True в параметре означает, что проверка на обоснованность по данному параметру прошла успешно, False – означает, что при проверке выявлены ограничения. Выходные параметры операции validity приведены в таблице ниже.
В случае, если указанный в запросе код услуги не найден в справочнике, или настройки ограничений не сделаны, сделаны неверно, отсутствуют для данной услуги - сервис вернет ошибку с HTTP кодом 422 и сообщением вида {"resourceType": "OperationOutcome","issue": [{"severity": "error","diagnostics": "%описание проблемы%"}]}

Интерпретация ответов метода

Пример файла запроса можно получить через службу технической поддержки. Метод может быть неактивен в учреждении.

Передача услуги (POST HealthcareService)

При работе сервиса существует необходимость ведения списка услуг, доступных к выполнению в данной МО, а также списка тестов, выполняемых в рамках данной услуги. Для реализации такого сервиса используется ресурс HealthcareService. Работа с данным ресурсом организуется следующим способом:

- Целевая МО, оказывающая перечень услуг, публикует этот перечень в сервисе путем передачи в сервис ресурсов HealthcareService (на каждую услугу передается один ресурс)
- Целевая МО может дополнительно указать для каждой услуги перечень тестов, входящих в данную услугу. Коды тестов передаются в составе ресурса HealthcareService, описывающего конкретную услугу
- Направляющая МО, использующая эти услуги в работе, запрашивает перечень доступных для целевой МО услуг и входящих в них тестов при помощи GET запроса ресурсов HealthcareService
Списком услуг, доступных для целевой МО, может управлять только данная МО. Запрашивать список доступных услуг может любая МО.
Для регистрации услуги в сервисе ДЛИ используется POST-запрос ресурса HealthcareService. В качестве адреса указывается URL в формате [base]/ HealthcareService?_format=json. В ответе сервис возвращает json с созданным ресурсом и его идентификатором в сервисе ДЛИ.
Для обновления услуги в сервисе ДЛИ также используется POST-запрос ресурса HealthcareService. При обновлении данных должна передаваться полная информация по услуге, т.е. HealthcareService необходимо передать со всеми параметрами, в том числе и неизменившимися. Обновление ресурса разрешено только отправителям данного ресурса.
Для деактивации услуги следует пользоваться параметром «Дата окончания действия». Принимающая информационная система должна корректно обрабатывать данный параметр.

Описание параметров

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

Таблица 33. Параметры HealthcareService

* Обязательно передается один код услуги, может передаваться один или несколько кодов тестов.

** Даты начала и окончания действия указываются «включительно», т.е. услуга с периодом действия 01/01/2018-13/12/2018 действует и 01/01/2018, и 13/12/2018. Даты начала и окончания действия указываются только для услуг, для тестов не требуется

Запрос списка услуг для заданной МО

Получение информации о списке услуг, оказываемых определенной МО, осуществляется с помощью GET запроса.
При запросе массива услуг в качестве адреса указывается URL в формате [base]/ HealthcareService?organization=[GUID]. Выходным параметром является JSON вида {"resourceType": "Bundle", "type": "searchset", "entry": [Х]}, где Х – это массив ресурсов HealthcareService, удовлетворяющих условиям запроса.

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

Правила передачи биоматериала

В общем случае биоматериал всегда должен быть передан в заявке и в результате (ресурс Specimen). При передаче результата допускается передавать как ссылку на биоматериал из заявки, так и передавать биоматериал в результате.
В случае, если в результате передается биоматериал, выполненный из биоматериала заявки, ссылка на исходный биоматериал должна быть передана в Specimen.parent.
При выполнении гистологических исследований процессы обработки биоматериала сложнее, чем при лабораторных исследованиях, и в общем случае выглядят следующим образом:
- отобранный гистологический материал пациента помещается во флакон с 10% раствором формалина и передается в лабораторию
- в лаборатории проводится контроль полученного биоматериала и выполняется макроописание
- из данного материала вырезается участок для проведения исследования
- выполняется проводка материала (подготовка биопсийного материала, в результате которого получается гистологический (парафиновый) блок (кассета))
- выполняется микротомирование (процесс обработки блока на микротоме и нарезки из него пластины биопсийного материала толщиной около 1 микрона)
- выполняется окраска гистологических образований в процессоре (иммуногистостенере) с получением еще одной формы материала – гистологических стекол. К стеклам применяется окраска, к одному стеклу может быть применена одна окраска. Если нужны разные окраски на один и тот же препарат - красят несколько стекол.
- выполняется микроскопия (изучение гистологических образований под видимым микроскопом)
Таким образом, информационными объектами в гистологии в рамках данного документа являются флакон, кассета, стекло.
Описание бизнес-процесса
1. От заказчика в заявке приходит флакон, один или несколько. Информация о флаконе передается в Specimen заявки (секция collection должна быть заполнена)
2. Из флакона делаются кассеты (они же блоки), из одного флакона делается одна или несколько кассет. Могут передаваться в результате. Могут ссылаться через Specimen.parent на флакон в заявке. Информация о кассете передается в Specimen результата (секция collection)
3. Из кассеты нарезаются стекла, из одной кассеты, опять же, одно или несколько. Информация о стеклах должна передаваться в Specimen результата (секция container должна быть заполнена, включая информацию об окраске). Нарезанные из кассеты стекла идут элементами массива Specimen.container, одно стекло - один элемент массива - у каждого своя окраска в additiveCodeableConcept.
Таким образом, Specimen заявки описывает флакон, Specimen результата – кассету и стёкла.
Частные случаи:
- если на исследование передается готовое стекло с окраской – то в заявке передается Specimen, описывающий это стекло. В результате можно сослаться сразу на это стекло.
- если на исследование передается готовый блок – то в заявке передается Specimen, описывающий этот блок. В результате можно передать ИЛИ описание полученных стекол, указав Specimen заявки как parent, ИЛИ повторно передать описание кассеты плюс описание полученных стекол.

Порядок передачи результата на заявку

Порядок (последовательность) передачи результата на заявку. Разрешенные для передачи через webAPI статусы OrderResponce:
1. review (частичная передача неподтвержденного результата, допускается многократная передача, ожидается передача окончательного результата)
2. accepted (частичная передача подтвержденного результата, допускается многократная передача, ожидается передача окончательного результата)
3. rejected (окончательная передача результата с браком, передается последним)
4. completed (окончательная передача результата без брака, передается последним)
5. completed + DiagnosticReport.status == appended (дополнительная передача результата после того, как был передан окончательный результат по п. 3, 4)

Передача результата частями

При отправлении результата на заявку частями (по мере выполнения исследований) каждая часть может быть отправлена отдельно, при этом необходимо указывать в поле OrderResponse.orderStatus значение статуса “accepted”. При отправлении последней части выполненного результата на заявку для OrderResponse.orderStatus нужно указать значение “completed ”, после чего заявка становится помеченная как выполненная, и возможность отправить еще результаты в ответ на данную заявку блокируется. При отправлении результата частями необходимо указывать для каждой части свой Идентификатор результата в ЛИС.

Передача информации о предварительном (не подтвержденном) результате

В случае, если исследование по заявке выполнено, но результат (или один из результатов) не является окончательным и требует подтверждения (подтверждающим тестом в этой же или референс-лаборатории), в сервис должна быть передана соответствующая информация.
В случае, если на заявку передается не окончательный результат – он должен всегда передаваться отдельным OrderResponce, в котором указан статус OrderResponse.orderstatus = review. Ресурсы DiagnosticReport, Observation, Binary в бандле результата передаются обычным образом. Причина признания результата предварительным передается текстом в поле description.
Передача не окончательного (не подтвержденного) результата в одном бандле с окончательными (подтвержденными) не допускается.

Передача информации об отсутствии результата

В случае, если исследование по заявке не выполнено полностью или частично (например, по причине порчи биоматерала), в сервис должна быть передана соответствующая информация.
Информация о невыполнении заказанных исследований полностью или частично всегда передается отдельным бандлом с OrderResponse, в котором указан статус OrderResponse.orderstatus = rejected. В ресурсах DiagnosticReport передаются невыполненные услуги. Причина отсутствия результата текстом передается в параметре description текстом и/или в параметре DiagnosticReport.code.extension по справочнику «Причина невыполнения лабораторного исследования». Observation, Binary в бандле не передаются.
DiagnosticReport передается следующим образом: должен быть указан статус DiagnosticReport.status = cancelled, параметры meta.security.code, result, presentedForm, codedDiagnosis, effectiveDatetime в DiagnosticReport не передаются.
В случае отсутствия необходимости детализации причины невыполнения исследования до уровня оказанной услуги в качестве ответа может быть передан только OrderResponse, в котором указан статус OrderResponse.orderstatus = rejected.

Передача уточненного результата

При отправлении результата в том случае, когда результат (или один из результатов) был уточнен после того, как результат был передан со статусом “completed”, он должен всегда передаваться отдельным OrderResponce, в котором указан статус “completed”, при этом DiagnosticReport.status должен быть “appended”

Передача результатов микробиологического исследования

Микробиологическое исследование всегда передается в рамках отдельного DiagnosticReport. В DiagnosticReport, описывающем результаты микробиологического исследования, параметр DiagnosticReport.category обязательно должен быть заполнен, код категории исследования должен соответствовать микробиологическим исследованиям.
Микробиологическое исследование состоит из следующих информационных объектов:
• Тест (описывающий собственно исследование)
• Микроорганизм (бактерии, грибы);
• Антибиотик (в случае проверки на чувствительность).
Тест на микробиологию проводится с целью выявления наличия или отсутствия в биоматериале микроорганизмов, а также воздействие антибиотиков и бактериофагов на выявленные микроорганизмы.
С целью культивирования микроорганизмов, определение их вида, производят посев исследуемого материала на различные бактериологические (питательные) среды. Далее, для каждого высеянного микроорганизма, если предусмотрено исследованием, применяется определенный перечень антибиотиков для определения устойчивости микроорганизма к нему.
Для передачи каждого объекта микробиологического исследования (найденные микроорганизмы, использованные антибиотики) используется ресурс Observation. Содержание ресурса определяется по полю Observation.system.

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

Схема отношения объектов предметной области микробиологических исследований

В общем случае результат микробиологического исследования может иметь до трех уровней вложенности (тест, микроорганизм, антибиотик). Самый верхний уровень – непосредственно тест, который был выполнен (1.2.643.5.1.13.13.11.1080 или 1.2.643.2.69.1.1.1.1 (только СПб)). Результат теста передается кодом интерпретации теста (DET в случае, если микроорганизмы выявлены, ND в случае, если не выявлены), числовые, текстовые значения результата и референтные значения могут не передаваться. Конкретные микроорганизмы, которые выявлялись или были выявлены в ходе данного теста, передаются в ресурсах Observation следующего уровня.

Связывание ресурсов Observation в нужную иерархическую структуру организовано по полю Observation.related, в котором для определенного теста указывается ссылка на связанный с данным тестом микроорганизм.
Таким образом, при передаче положительных (микроорганизмы выявлены) результатов теста в ресурсе Observation верхнего уровня, необходимо указывать в параметре Observation.related ссылки на Observation, описывающие участвовавшие в исследовании микроорганизмы. В случае, когда в лабораторном исследовании никакие микроорганизмы не выявлены, эти данные не передаются.
Observation следующего уровня – конкретный микроорганизм, который выявлялся в ходе теста (по справочнику 1.2.643.5.1.13.13.11.1087 для бактерий, 1.2.643.5.1.13.13.11.1088 для грибов). В случае, если в ходе теста проводилось исследование чувствительности к антибиотикам, информация об антибиотиках передается в ресурсах Observation следующего уровня (по справочнику 1.2.643.5.1.13.13.99.2.1127 или 1.2.643.2.69.1.1.1.74 – в зависимости от региональных настроек).
Связывание ресурсов Observation в нужную иерархическую структуру организовано по полю Observation.related, в котором для определенного микроорганизма указывается ссылка на использованный антибиотик.
Таким образом, при передаче микроорганизма в ресурсе Observation, необходимо указывать в параметре Observation.related ссылки на все использованные в исследовании антибиотики. В случае, когда в лабораторном исследовании не определялась чувствительность к антибиотикам, эти данные не передаются.
Передача информации о выявлении роста или об отсутствии роста для конкретного микроорганизма осуществляется путем передачи значения в поле interpretation – DET (Обнаружено) и ND (Не обнаружено) соответственно. При наличии может быть передан количественный (например, количество выявленных бактерий) или текстовый (например, «Нет в поле зрения») результат.
Передача информации о чувствительности к тому или иному антибиотику для конкретного микроорганизма осуществляется путем передачи значения в поле interpretation. Рекомендуемые значения: R (Устойчивый), S (Чувствительный), I (Умеренно-устойчивый).
Передача информации об отсутствии роста микрофлоры осуществляется путем передачи ресурса Observation верхнего уровня с указанием значения ND (Не обнаружено) в поле interpretation.
В случае, если необходимо выделение категории DiagnosticReport «Чувствительность к антимикробным и дезинфицирующим препаратам», возможны две схемы передачи микробиологического результата:
1. ОДИН DiagnosticReport с кодом категории 601 «Микробиологические исследования», в котором указан код услуги из группы «микробиологическое исследование», в котором указан код услуги из группы «определение чувствительности» и к которому иерархически привязаны все три уровня Observation - тест, выявленные микроорганизмы, использованные антибиотики (рекомендуемый способ)
2. ДВА DiagnosticReport (требуется доработка сервиса):

2.1. Один с кодом категории 601 «Микробиологические исследования», в котором указан код услуги из группы «микробиологическое исследование», к которому иерархически привязаны два уровня Observation - тест и выявленные микроорганизмы,
2.2. Второй с кодом категории 602 «Чувствительность к антимикробным и дезинфицирующим препаратам», в котором указан код услуги из группы «определение чувствительности» и к которому иерархически привязан последний уровень Observation - использованные антибиотики.
В обоих случаях иерархическая связанность Observation между собой не меняется.

Передача заявки и результатов гистологического исследования

В медицинском документообороте для направлений и результатов гистологических исследований применяются учетные формы «№ 014/у Направление на прижизненное патолого-анатомическое исследование биопсийного (операционного) материала» и «№ 014-1/у Протокол прижизненного патолого-анатомического исследования биопсийного (операционного) материала». Состав полей и правила их заполнения определены Приказом Министерства здравоохранения РФ от 24 марта 2016 г. N 179н "О Правилах проведения патолого-анатомических исследований".
Таким образом, при передаче информации по заявкам и результатам гистологических исследований необходимо передавать все данные, предусмотренные указанными учетными формами. Часть информации является стандартной (описание врача, пациента, заявки и др.), и передается таким же образом, как и для всех исследований. Для передачи дополнительной информации, характерной только для гистологических исследований, используются дополнительные параметры, предусмотренные для ресурсов Specimen, Observation, DiagnosticReport.
Заявку и результат гистологического исследования необходимо передавать отдельными бандлами, не в составе общего бандла заявки или результата с иными исследованиями.
Бандл результата гистологического исследования:
- определяется системой как гистология по параметру DiagnosticReport.category. coding.code (обязательна при передаче результата), код категории исследования должен соответствовать гистологическим исследованиям
- должен содержать только один DiagnosticReport. В случае, если в заявке передано несколько различных образцов к различным DiagnosticOrder – DiagnosticReport может быть по количеству DiagnosticOrder. В этом случае все DiagnosticReport должны ссылаться на одни и те же Observation, описывающие результат и каждый DiagnosticReport должен ссылаться на свой DiagnosticOrder и Specimen.

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

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

В ходе гистологических исследований, помимо данных, предусмотренных учетной формой «№ 014-1/у Протокол прижизненного патолого-анатомического исследования биопсийного (операционного) материала» (Приказ Министерства здравоохранения РФ от 24 марта 2016 г. N 179н "О Правилах проведения патолого-анатомических исследований") необходимо также передавать ряд параметров, описывающих выявленную онкологическую патологию, а именно:
• Топографические и морфологические коды МКБ-О
• Параметры опухоли (pT, pN, pM, ypT, ypN, ypM, Стадия, Уровень дифференцировки тканей)

Топографические и морфологические коды МКБ-О передаются как необязательные параметры DiagnosticReport.codedDiagnosis, совместно с обязательным диагнозом по МКБ-10, кодируются по федеральным справочникам «МКБ-О-3 Морфология» (OID 1.2.643.5.1.13.13.11.1486) и «МКБ-О-3 Топография» (OID 1.2.643.5.1.13.13.11.1487)
Стадирование злокачественных опухолей передается отдельными Observation, при этом тип передаваемого параметра кодируется в Observation.code.coding (по федеральному справочнику «TNM. Стадирование злокачественных опухолей» OID 1.2.643.5.1.13.13.99.2.546 или по региональному справочнику «Параметры опухоли» OID 1.2.643.2.69.1.1.1.146), а передаваемое значение в Observation.valueCodeableConcept.
Уровень дифференцировки тканей передаются отдельными Observation, при этом тип передаваемого параметра кодируется в Observation.code.coding (по федеральному справочнику «Степень дифференцировки опухоли» OID 1.2.643.5.1.13.13.99.2.1046 или по региональному справочнику «Параметры опухоли» OID 1.2.643.2.69.1.1.1.146), а передаваемое значение в Observation. valueCodeableConcept.
Перечень параметров и правила их применения приведены в таблице ниже.

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

Передача заявки и результатов цитологического исследования

В медицинском документообороте для направлений и результатов цитологических исследований применяются учетные формы N 203/у-02 «Направление на цитологическое диагностическое исследование и результат исследования» и N 446/у «Направление на цитологическое исследование и результат исследования материала, полученного при профилактическом гинекологическом осмотре, скрининге». Состав полей и правила их заполнения определены Приказом Министерства здравоохранения 24.04.2003 N 174 «Об утверждении учетных форм для цитологических исследований».

Таким образом, при передаче информации по заявкам и результатам цитологических исследований необходимо передавать все данные, предусмотренные указанными учетными формами. Часть информации является стандартной (описание врача, пациента, заявки и др.), и передается таким же образом, как и для всех исследований. Для передачи дополнительной информации, характерной только для цитологических исследований, используются дополнительные параметры, предусмотренные для ресурсов Specimen, Observation, DiagnosticReport.
Заявку и результат цитологического исследования необходимо передавать отдельными бандлами, не в составе общего бандла заявки или результата с иными исследованиями.
Бандл результата цитологического исследования:
- определяется системой как цитология по параметру DiagnosticReport.category.coding.code (обязательна при передаче результата), код категории исследования должен соответствовать цитологическим исследованиям
- должен содержать только один DiagnosticReport
- должен содержать как минимум один Observation с Observation.code.coding.system "urn:oid:1.2.643.5.1.13.13.11.1080" или "urn:oid: 1.2.643.2.69.1.1.1.1" (только СПб), в котором в параметре valueString передается текстовое описание результата
Пример файла запроса можно получить через службу технической поддержки. Метод может быть неактивен в регионе.
Перечень параметров и правила их применения приведены в таблице ниже. Все параметры являются обязательными.

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

Выгрузка результатов исследований в ВИМИС

На данный момент реализована следующая схема работы с ВИМИС: CDA документы для передачи в ВИМИС формируются на стороне МО-исполнителя и передаются в составе бандла результата, результата без заявки при наступлении требуемого события и в автоматическом режиме выгружаются в ВИМИС. При этом в ВИМИС могут выгружаться как СЭМД, так и СЭМД бета
Таким образом, МО-исполнитель самостоятельно формирует CDA документ для выгрузки в ВИМИС в соответствии с актуальным описанием, размещенном на портале оперативного взаимодействия участников ЕГИСЗ http://portal.egisz.rosminzdrav.ru/materials и передает его в составе бандла результата, результата без заявки в ресурсе Binary
Для возможности выгрузки переданных CDA документов в ВИМИС при передаче ресурса Binary с CDA документом ВИМИС корректно заполнить параметр Binary.meta.tag (см. описание передачи ресурса Binary), при этом:

в параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1520 для СЭМД или 1.2.643.5.1.13.13.99.2.592 для СЭМД бета),
в параметре version указывается версия справочника в сервисе Терминологии,
в параметре code указывается код значения из справочника, соответствующий передаваемому документу
в параметре display указывается код значения из справочника, соответствующий версии передаваемого ВИМИС документа (docTypeVersion),
В случае, если параметр Binary.meta.tag заполнен неверно или отсутствует, передача документа в ВИМИС невозможна.
На данный момент в формате СЭМД бета должны выгружаться только направления на неонатальный скрининг (указывается contentType application/x-akineo)
Все результаты исследований, подлежащие выгрузке в ВИМИС (лабораторные, цитологические, ПАО) должны передаваться в формате СЭМД (указывается contentType application/xml). Передача СЭМД бета не требуется. Передача СЭМД с contentType, отличным от application/xml, не допускается. Параметр meta.tag должен быть корректно заполнен

Рекомендуемые параметры Binary для передачи документов в ВИМИС

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

Выгрузка результатов исследований в РЭМД

Для возможности передачи протоколов лабораторных исследований в федеральный сервис РЭМД (http://portal.egisz.rosminzdrav.ru/materials/1879) необходимо обеспечить выполнение ряда условий:
- у врача-исполнителя и пациента должен быть указан корректный СНИЛС;
- результат должен передаваться от имени структурного подразделения (ТВСП). Результаты, переданные от имени головной МО, не выгружаются в РЭМД;
- совместно с протоколом исследования должны передаваться электронные подписи – УКЭП врача и УКЭП МО. УКЭП должна передаваться в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012;

- протокол исследования может передаваться в форматах, разрешенных справочником https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.11.1520 ;
- тип и версия передаваемого в РЭМД документа должны быть указаны в параметре Binary.meta.tag;
- протоколы исследования и УКЭП в формате base64binary передаются в ресурсах Binary, ссылки на эти ресурсы передаются в DiagnosticReport, тип содержимого в ресурсе передается через параметр ContentType.
Детальная информация приведена в описании правил передачи ресурса Binary
При передаче документов в федеральный сервис РЭМД накладываются определенные ограничения на передаваемые данные, поэтому при включенной интеграции с РЭМД в сервисе ОДЛИ включаются дополнительные проверки:
1. Проверяется наличие СНИЛС врача:
- передаваемый в бандле ресурс Practitioner должен содержать СНИЛС врача. Параметр identifier с identifier.system = urn:oid:1.2.643.2.69.1.1.1.6.223 должен быть, identifier.value не может быть пустым
2. Запрещается передача результатов исследований без УКЭП врача и УКЭП МО
3. Передаваемая УКЭП врача проверяется:
- на соответствие СНИЛС врача, указанного в файле УКЭП, и СНИЛС врача, указанного в DiagnosticReport.performer.reference.
- на соответствие ФИО врача, указанного в файле ЭЦП, и ФИО врача, указанного в DiagnosticReport.performer.reference
- на соответствие передаваемому протоколу PDF.
4. Передаваемая УКЭП МО проверяется:
- на соответствие ОГРН МО, указанного в файле УКЭП, и ОГРН МО, указанный в справочнике МО для МО, указанной в OrderResponce.who
- на соответствие передаваемому протоколу PDF.
В случае невыполнения указанных условий сервис возвращает соответствующие ошибки. Если результат принят сервисом – он считается прошедшим базовые проверки и пригодным для выгрузки в РЭМД.
Непосредственно выгрузка в федеральные сервисы (СЭМД, РЭМД) осуществляется отдельными сервисами, не являющимися частью ОДЛИ. При передаче сведений в федеральные сервисы дополнительно проверяется совпадение передаваемой организации, должности врача, СНИЛС врача на соответствие данным ФРМР, а также выполняется форматно-логический контроль. Все вопросы по выгрузке результатов в федеральные сервисы, включая получение логов, следует адресовать в подразделение, ответственное за выгрузку.

Передача УКЭП для структурированных данных

Описание

Особенность реализации сервиса такова, что в БД сервиса хранятся данные, в которых изменены атрибуты – параметр fullUrl заменяется на ссылку на ресурс. В ряде случаев необходимо иметь в сервисе юридически значимые структурированные данные, переданные МИС или ЛИС с УКЭП. Данный механизм реализуется следующим образом:
1. Особым образом подготовленный JSON с данными подписывается УКЭП как текстовый файл и передается в сервис вместе с УКЭП. Передаваемая УКЭП проверяется:
• на соответствие ОГРН МО, указанного в файле УКЭП, и ОГРН МО, указанный в справочнике МО для МО, передающей ресурс или бандл
• на соответствие передаваемым структурированным данным
2. Если проверки не выполняются, сервис возвращает соответствующие ошибки
3. Если проверки выполняются, в БД сервиса сохраняются УКЭП и переданный бандл в неизменном виде
4. В случае необходимости проверки хранящихся в сервисе данных необходимо:
• штатными средствами ОДЛИ запрашиваются необходимые данные (заявка, результат) и фиксируются требуемые данные
• средствами администрирования БД получается исходный бандл и УКЭП для него
• средствами проверки УКЭП (КриптоПро и т.п.) проверяется соответствие исходного бандла и хранящейся с ним УКЭП
• средствами просмотра JSON проверяется соответствие данных, запрошенных из ОДЛИ штатными средствами, и исходного бандла
Если исходный бандл прошел проверку УКЭП и данные, запрошенные из ОДЛИ штатными средствами, и исходный бандл соответствуют друг другу, то структурированные данные в сервисе признаются юридически значимыми.

Техническая реализация

Совместно с результатом исследования должна передаваться УКЭП МО. УКЭП должна передаваться в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012 и передаваться в формате base64binary в HTTP заголовке (header) signature. Пример передачи:
signature: MIIThvcNAQcCoIITZjCCE2ICAQExDjAMBggqhQMHAQECAgUAMAsGCSqGSIb3DQEHAa...
Для возможности валидации передаваемых данных на соответствие переданной с ними УКЭП JSON c данными (ресурс, бандл) должны быть минимизированы (JSONmin). JSON не должен содержать символы перевода строк, возврата каретки, пробелы, символы табуляции и другие символы. JSON должен быть корректен по структуре (валидный JSON). Пример передачи:
{"resourceType":"Bundle","type":"transaction","meta":{"profile":["Struct...

Работа с сервисом Терминологии

Для корректной работы подсистемы ОДЛИ смежные инфосистемы должны поддерживать методы сервиса Терминологии. Актуальная информация по работе с сервисом Терминологии находится по адресу Терминология.

Должны поддерживаться следующие методы:

• Запрос справочника
• Запрос списка версий справочника
• Запрос значений справочника ($expand)
• Поиск значения в справочнике ($lookup)
• Валидация значения в справочнике ($validate-code)
• Поиск соответствия кода услуги справочнику 1.2.643.5.1.13.13.11.1070

Запрос справочника

Получение информации о справочнике осуществляется с помощью GET-запроса. В качестве адреса должен быть указан URL в формате [base]/ValueSet?_format=json&url=urn:oid:[OID справочника].

Пример запроса:

Запрос списка версий справочника

Получение информации о списке версий справочника осуществляется с помощью GET-запроса. В качестве адреса должен быть указан URL в формате [base]/ValueSet/[идентификатор справочника в сервисе Терминологии]/$versions?_format=json.

Пример запроса:

Запрос значений справочника ($expand)

Получение значений заданного справочника осуществляется с помощью POSTзапроса по URL в формате [base]/ValueSet/$expand. Метод возвращает метаинформацию о справочнике и пары код-значение.

Пример запроса приведен в разделе "Примеры запросов".

Поиск значения в справочнике ($lookup)

Метод предназначен для получения дополнительной информации о значении справочника по коду этого значения. Поиск заданного значения в справочнике осуществляется с помощью POST-запроса по URL в формате [base]/ValueSet/$lookup. Метод возвращает json с детализированной информацией о значении, которое соответствует коду значения из запроса.

Пример запроса приведен в разделе "Примеры запросов".

Валидация значения в справочнике ($validate-code)

Метод предназначен для получения дополнительной информации о значении справочника по коду этого значения. Поиск заданного значения в справочнике осуществляется с помощью POST-запроса по URL в формате [base]/ValueSet/$lookup. Метод возвращает json с детализированной информацией о значении, которое соответствует коду значения из запроса.

Пример запроса приведен в разделе "Примеры запросов".

Поиск соответствия кода услуги справочнику 1.2.643.5.1.13.13.11.1070

Метод предназначен для получения кода соответствия услуги из справочника 1.2.643.2.69.1.1.1.31 коду услуги по справочнику 1.2.643.5.1.13.13.11.1070. Поиск заданного значения осуществляется с помощью POST-запроса по URL в формате [base]ConceptMap/translate?_format=json. Метод возвращает json с детализированной информацией о значении, которое соответствует коду значения из запроса по справочнику 1.2.643.5.1.13.13.11.1070.

Пример запроса приведен в разделе "Примеры запросов".

Регламент подключения МИС/ЛИС к сервису ОДЛИ, ОДИИ, ОДР

1. Направить оператору РС ЕГИСЗ (МИАЦ или МЗ региона) извещение о намерении подключить МИС/ЛИС/РИС/РМИС к требуемому сервису. Запросить контакты службы технической поддержки (СТП).
2. Направить на адрес электронной почты СТП заявку на подключение к тестовому стенду требуемого сервиса. На каждый сервис подается отдельная заявка, которая должна содержать следующие данные:
   • Наименование компании разработчика ЛИС/МИС/РИС/РМИС с указанием формы собственности;
   • Наименование ЛИС/МИС/РИС/РМИС;
   • Роли, выполняемые ЛИС/МИС/РИС/РМИС в сервисе (передача заявок, результатов, рецептов и др.);
   • Контактные данные ответственного за интеграцию сотрудника (ФИО, почта, телефон).

   Ответ СТП будет содержать:

   • Ссылки на тестовый сервис и НСИ (справочники, используемые при обмене данными);
   • Ссылка на документ «Описание интеграционных профилей»;
   • Реквизиты доступа к сервису (авторизационный токен, OID).
3. Если в МО принято решение о передаче PDF/xml протоколов с УКЭП, дополнительно должны быть предоставлены:
   • Корневые сертификаты удостоверяющих центров (УЦ), чьи подписи используются для работы с сервисом;
   • Сертификаты промежуточных УЦ, если таковые используются в УЦ, чьи подписи используются для работы с сервисом;
   • Списки отзыва (ссылки на них в сети интернет) сертификатов всех УЦ, чьи подписи используются для работы с сервисом;
   • Образец протокола PDF/xml и открепленные подписи к нему в виде файлов.
4. Для получения консультаций в процессе работы с сервисом следует отправлять запросы на адрес электронной почты СТП. Запрос на консультацию должен содержать:
   • Наименование сервиса;
   • Тип площадки (тестовая, продуктивная);
   • URL куда отправляется запрос;
   • Тип запроса (POST или GET);
   • Авторизационный токен, указываемый в запросе;
   • Лог в *txt запроса к сервису и ответа сервиса на запрос;
   • Идентификатор N3RID, полученный в ответе сервиса;
   • Сам вопрос по работе сервиса.
5. Завершив работы по интеграции с тестовым стендом, передать в тестовый стенд корректные примеры запросов. Запросы по передаче тестового пациента должны включать как минимум данные по ФИО, полу, ДР пациента, данные полиса ОМС и СНИЛС. Запросы по передаче тестового врача должны включать как минимум данные по ФИО, должности, специальности врача, данные СНИЛС.

ОДЛИ

Тестовые заявки на лабораторные исследования должны удовлетворять следующим требованиями:

• Вид оплаты ОМС;
• Наличие биоматериала в заявке.

Тестовые результаты лабораторных исследований (ОДЛИ) должны удовлетворять следующим требованиями:

• Должны быть переданы все виды исследований, выполняемых ЛИС
• Для клинических результатов (гематология, биохимия и др.) должны быть переданы результаты как с численными, так и с текстовыми показателями, а также результаты с ответом о порче материала или невыполнении исследования (если применимо). Передача численных показателей текстом (ValueString) не допускается
• Для микробиологических результатов должны быть переданы результаты вида «микроорганизм не выявлен», «микроорганизм выявлен, антибиотикочувствительность не определялась», «микроорганизм выявлен, антибиотикочувствительность определялась»
• Для гистологических и цитологических результатов должны быть переданы все параметры, предусмотренные действующими отчётными формами
• PDF/xml протокол, передаваемый с результатом, должен соответствовать переданным в результате структурированным данным и удовлетворять требованиям, указанным в документации
• Если в принято решение о передаче PDF/xml протоколов в федеральный сервис РЭМД, примеры должны содержать протоколы, подписанные согласно требованиям документации

ОДИИ

Тестовые заявки на инструментальные исследования должны удовлетворять следующим требованиями:

• Вид оплаты ОМС;
• Наличие данных пациента (рост, вес) в заявке.

Тестовые результаты инструментальных исследований должны удовлетворять следующим требованиями:

• Если есть возможность передачи данных изображения с возможностью просмотра через viewer - должны быть переданы описание, заключение в структурированном виде, протокол PDF/xml, данные о снимке.
• Если возможность передачи данных изображения с возможностью просмотра через viewer отсутствует - должны быть переданы описание, заключение в структурированном виде, протокол PDF/xml.
• Если принято решение о передаче PDF/xml протоколов в федеральный сервис РЭМД, примеры должны содержать протоколы, подписанные согласно требованиям документации.

ОДР

Тестовые рецепты должны удовлетворять следующим требованиями:

• переданы все виды рецептов, формируемые в МО;
• бланк рецепта в PDF/xml подписан согласно требованиям документации.

6. Направить на адрес электронной почты СТП извещение о завершении работ и сообщить параметры, необходимые для запроса из тестового стенда тестовых данных, переданных ЛИС/МИС/РИС/РМИС (идентификатор Bundle, присвоенный сервисом).
7. При отсутствии ошибок в тестовых данных СТП по согласованию с оператором РС ЕГИСЗ выдаст реквизиты доступа к промышленному стенду соответствующего сервиса.

Методические рекомендации

Введение

Данный документ разъясняет особенности практического применения интеграционных профилей, описанных в документе «ОПИСАНИЕ ИНТЕГРАЦИОННЫХ ПРОФИЛЕЙ. СЕРВИС ДЛИ» (ОИП). Данный документ не отменяет и не изменяет требования, описанные в ОИП. Данный документ не описывает все положения ОИП, а лишь разъясняет особенности применения тех или иных методов. Правила практического применения, описанные в данном документе, основаны на обработке вопросов участников информационного взаимодействия, поступающих разработчику сервиса. При наличии предложений по расширению и совершенствованию данного раздела, просьба направлять их по электронной почте по адресу: a.narykov@n3health.ru , копия: a.shulyatev@n3health.ru

Общие сведения

Использование справочника организаций

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

В случае распределенной работы учреждения (бизнес-процесс лечения и исследования распределен на несколько подразделений и отделений) следует пользоваться следующими правилами: Если пациент числится в отделении А, лечится в отделении Б, заявку ему делают в подразделении В, врач работает в подразделении Г, а забор материала делается в подразделении Д, то:

• идентификатор МО в случае лечения (Encounter), в заявке (Order), и в пациенте, передаваемом в составе bundle заявки, должны быть равны. Оформление заявки на ЛИ вне рамок случая лечения, а также в рамках случая лечения в другом подразделении не допускается. Допускается оформление заявки на ЛИ со ссылкой на ранее переданного в сервис пациента, при этом пациент может быть зарегистрирован ранее от имени другого подразделения данной МО
• идентификатор МО врача может отличаться от вышеперечисленных идентификаторов в случае лечения и заявке (заявку на ЛИ может оформить в т.ч. врач другого подразделения данной МО)
• идентификатор МО для биоматериала не предусмотрен, т.е. место забора в сервис на данный момент не передается, требований по идентификатору МО при передаче биоматериала нет

Правила валидации данных

Сервис осуществляет валидацию входных данных при вызовах методов ОДЛИ.

Валидируются следующие данные:

• Авторизационные данные, передаваемые в заголовках (headers) метода.
• Данные, передаваемые в пути (path) запроса. Пример: передача GUID в GET запросах.
• Данные, передаваемые в теле (body) запроса:
  • Уникальность передаваемых данных (обрабатывается отдельно для каждого ресурса).
  • Валидация структуры (передаваемые данные).
  • Валидация обязательности заполнения параметров.
  • Валидация значений параметров:
    • Тип данных.
    • Значение согласно справочникам.

При валидации можно выделить следующие общие правила проверки:

Ссылки на ресурсы

При передаче данных методами ОДЛИ необходимо указывать связи между ресурсами. Данные связи называются ссылками и указываются в соответствующих параметрах. Для таких параметров указывается тип данных Reference.

Пример связей:

• В какой организации работает врач.
• Какому пациенту создана заявка на исследование.

В методах ОДЛИ используются два типа ссылок:

• Ссылка на внутренний ресурс, передаваемый в Bundle.
• Ссылка на уже созданный ранее ресурс.

В соответствии с этими типами ссылка должна передаваться определенной схемой.

Использование fullUrl

При передаче любого ресурса в сервис (пример отдельных ресурсов - врач, пациент) - в ответе сервиса вернется переданный ресурс с присвоенным id. Этот id - уникальный идентификатор ресурса в сервисе, его можно в любой момент запросить GET запросом вида (адрес сервиса)/(имя ресурса)/(id)

При передаче бандла (связки ресурсов), то при передаче к каждому ресурсу добавляется fullURL (присваивается в МИС), это нужно для связки между ресурсами. Т.е., например, в бандле передается случай обслуживания, у него указан "fullUrl":"urn:uuid:f0ceca14-6847-4ea4-b128-7c86820da555", в этом случае мы сошлемся на него в DiagnosticReport по ссылке "encounter": {"reference":"urn:uuid:f0ceca14-6847-4ea4-b128-7c86820da555"}

Когда бандл обработается сервисом, все fulurl заменятся на id ресурса, все ссылки на fullurl заменятся на ссылки на ресурсы вида "encounter": {"reference":"Encounter/af2a113aed05-4d82-8633-bca6b76736d5"}

Методы работы с сервисом

В сервисе ОДЛИ реализовано несколько методов. Для полноценного использования сервиса необходима поддержка всех методов как со стороны МИС (передача направления, запрос результата), так и со стороны ЛИС (запрос направления, передача результата).

В таблице ниже указана обязательность поддержки методов со стороны МИС и ЛИС, а также возможные варианты поддержки методов.

Передача пациента

Общие положения

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

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

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

Запрещается:

• передача различных пациентов (разные физические лица) с одним идентификатором МИС из одной МО
• передача одного пациента (одно физическое лицо) с разными идентификаторами МИС из одной МО

Требования к передаче данных:

• обязательно передавать все известные идентификаторы пациента: СНИЛС, ДУЛ, полисы
• рекомендуется передавать все известные данные пациента (адрес по прописке и регистрации, место рождения и др.)

Ограничения сервиса:

• передача заявки с типом оплаты «ОМС» возможна только в том случае, если для пациента был передан полис ОМС. Передача заявки с типом оплаты «ДМС» возможна вне зависимости от переданного полиса ДМС
• для пациента возможна передача только одного полиса ОМС (ЕП, временное св-во, полис старого образца) и только одного ДУЛ данного вида (например, нельзя передать ЕП и временное св-во, или два паспорта РФ)

Передача прикрепления в сервисе ОДЛИ

Правила передачи идентификатора с OID 1.2.643.5.1.13.2.7.100.9:

• если Patient.identifier.value = 0, то идентификатор может передаваться только один, иначе – идентификаторов приклепления может быть несколько
• запрещена передача нескольких идентификаторов прикрепления с одинаковым Patient.identifier.value

Назначение параметров и правила валидации

Пример передачи прикрепления:

{
 "system": "urn:oid:1.2.643.5.1.13.2.7.100.9",
 "use": "temp",
 "type": {
   "coding": [
     {
      "system": "urn:oid:{XXXXXXXXXXXXXXX}",
      "version": "1",
      "code": "1"
     }
   ]
  },
 "value": "0",
 "period": {
   "start": "2010-05-05",
   "end": "2018-05-05",
 },
 "assigner": {
     "reference": "Organization/a762831e-dd4c-46be-a329-6dd592a14bb6"
  }
}

Бизнес-логика

Передача пациента

Для регистрации пациента в сервисе ДЛИ используется POST-запрос ресурса Patient. Структура передаваемых данных в ресурсе Patient описана в документе Описание Интеграционных Профилей сервиса ДЛИ.

Уникальность ресурса Patient определяется по следующим параметрам:

• identifier.assigner (где identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5),
• identifier.value,
• identifier.assigner.display,
• Patient.managingOrganization.

По приведенным выше параметрам при передаче ресурса Patient осуществляется поиск пациента в сервисе ДЛИ. В случае, когда:

1. Пациент не найден в БД, создается новый пациент и сервис в ответ возвращает json с созданным пациентом и его идентификатор в сервисе ДЛИ.
2. Пациент найден в БД, происходит обновление пациента, сервис в ответ возвращает json с обновленным пациентом, а также его идентификатор в сервисе ДЛИ. При обновлении ресурса Patient необходимо передавать все параметры, в том числе и неизменившиеся. Обновление ресурса Patient допускается только для той организации (подразделения), которая изначально зарегистрировала пациента.

Обновление пациента (PUT)

Для обновления пациента используется PUT-запрос ресурса Patient. Операция обновления создает новую текущую версию ресурса. Структура передаваемых данных в ресурсе Patient описана в документе Описание Интеграционных Профилей сервиса ДЛИ. При обновлении ресурса Patient необходимо передавать все параметры, в том числе и неизменившиеся, а также id ресурса в сервисе. Если указанный ресурс Patient не найден в БД, то сервис возвратит ошибку: «Ресурс не найден».

При операции PUT Patient бизнес-логика обновления следующая:

1. В теле ресурса Patient ничего не изменилось, то ничего не происходит, сервис возвращает найденный ресурс Patient;
2. Есть изменения в теле пациента, кроме параметров, по которым определяется уникальность ресурса:
   • identifier.assigner (где identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5),
   • identifier.value,
   • identifier.assigner.display,

   то происходит ОБНОВЛЕНИЕ ресурса операция PUT;

3. Если изменения в параметрах, по которым определяется уникальность ресурса:
   • identifier.assigner (где identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5),
   • identifier.value,
   • identifier.assigner,

   то возвращается ошибка;

Обновление ресурса разрешено ТОЛЬКО отправителям данного ресурса. В случае попытки изменения ресурса, заведенного другим ЛПУ или другой ИС, сервис возвратит ошибку: "Доступ редактирования для данного OID передающей ИС или ЛПУ запрещен".

Передача врача

Общие положения

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

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

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

Бизнес-логика

Передача врача

Для регистрации врача в сервисе ДЛИ используется POST-запрос ресурса Practitioner. Структура передаваемых данных в ресурсе Practitioner описана в соответствующем разделе документа Описание Интеграционных Профилей сервиса ДЛИ.

Уникальность ресурса Practitioner определяется по следующим параметрам:

• Practitioner.identifier.value;
• Practitioner.Identifier.system;
• Practitioner.practitionerRole.managingOrganization;
• Practitioner.specialty;
• Practitioner.role.

По приведенным выше параметрам при передаче ресурса Practitioner осуществляется поиск врача в сервисе ДЛИ. В случае, когда:

1. Врач не найден в БД, создается новый врач и сервис в ответ возвращает json с созданным врачом и его идентификатор в сервисе ДЛИ.
2. Врач найден в БД, происходит обновление врача, сервис в ответ возвращает json с обновленным врачом, а также его идентификатор в сервисе ДЛИ. При обновлении ресурса Practitioner необходимо передавать все параметры, в том числе и неизменившиеся.

Обновление врача (PUT)

Для обновления врача используется PUT-запрос ресурса Practitioner. Операция обновления создает новую текущую версию ресурса. Структура передаваемых данных в ресурсе Practitioner описана в документе Описание Интеграционных Профилей сервиса ДЛИ. При обновлении ресурса Practitioner необходимо передавать все параметры, в том числе и неизменившиеся, а также id ресурса в сервисе. Если указанный ресурс Practitioner не найден в БД, то сервис возвратит ошибку: «Ресурс не найден».

При операции PUT Practitioner бизнес-логика обновления следующая:

1. В теле ресурса Practitioner ничего не изменилось, то ничего не происходит, сервис возвращает найденный ресурс Patient;
2. Есть изменения в теле врача, кроме следующих параметров:
   • identifier.assigner (где identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5),
   • identifier.value,
   • practitionerRole.managingOrganization,

   то происходит ОБНОВЛЕНИЕ ресурса операция PUT;

3. Если изменения в следующих параметрах:
   • identifier.assigner (где identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5),
   • identifier.value,
   • practitionerRole.managingOrganization,

   то возвращается ошибка;

Обновление ресурса разрешено ТОЛЬКО отправителям данного ресурса. В случае попытки изменения ресурса, заведенного другим ЛПУ или другой ИС, сервис возвратит ошибку: "Доступ редактирования для данного OID передающей ИС или ЛПУ запрещен".

Передача заявки

Общие положения

Заявка должна всегда передаваться за один раз, полностью, с уникальным идентификатором в МИС. Передача заявки частями не допускается. Передача заявки с тем же идентификатором в МИС не допускается.

Если источник финансирования в заявке ОМС, то для пациента должен быть передан полис ОМС.

Идентификатор МО в случае лечения (Encounter), в заявке (Order), и в пациенте, передаваемом в составе bundle заявки, должны быть равны.

Идентификатор биоматериала (штрих-код) должен быть уникален для данной передающей МИС на протяжении как минимум срока жизни образца, рекомендуется – на протяжении как минимум трех месяцев.

Штрихкод может содержать только цифры и буквы латинского алфавита. Не может содержать пробелы и любые другие символы.

Бизнес-логика

Для передачи заявки используется POST-запрос передачи ресурса Bundle. Ресурс Bundle представляет собой контейнер ресурсов, необходимых для передачи информации о заявке.

Уникальность заявки (ресурса Bundle) определяется по следующим параметрам:

• Order.identifier.value;
• Order.identifier.system;
• Order.identifier.assigner.

При повторном добавлении заявки сервис ДЛИ возвращает ошибку вида «Повторное добавление заявки».

При передаче ресурсов Patient, Practitioner в составе Bundle осуществляется поиск этих ресурсов по уникальным параметрам в сервисе ДЛИ. В случае, когда:

1. Ресурсы найдены (Practitioner, Patient) в БД, происходит обновление ресурса, сервис возвращает в ответ json Bundle заявки с созданными/обновленными ресурсами и их идентификаторами в сервисе.
2. Ресурсы не найдены (Practitioner, Patient) в БД, создаются не найденные ресурсы передаваемые в Bundle, сервис возвращает в ответ json Bundle заявки с созданными ресурсами и их идентификаторами в сервисе.

Проверка полиса пациента

При отправлении POST Bundle заявки осуществляется проверка передаваемого источника финансирования и наличие полиса у пациента.

При передаче POST Bundle заявки, в случае когда в параметре DiagnosticOrder.item.code.extension.valueCodeableConcept.coding.code передается код из справочника 1.2.643.2.69.1.1.1.32, соответствующий источнику финансирования – ОМС (указывается в конфигурационном файле) осуществляется проверка наличия у пациента полиса ОМС. При отсутствии полиса ОМС операция POST Bundle заявки завершится ошибкой вида «Требуется страховой полис для пациента».

Обновление информации в заявке после забора биоматериала

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

• в ходе приема пациента врачом формируется заявка на лабораторное исследование и через МИС передается в сервис ОДЛИ методом, указанным в разделе «Передача заявки (POST Bundle заявки)» данного документа. При этом в ресурсе Specimen заполняется только параметр Specimen.subject.reference, т.к. на данном этапе другой информации по биоматериалу нет. Количество ресурсов Specimen, передаваемых с заявкой, должно соответствовать количеству биоматериала, подлежащего забору.
• перед забором биоматериала МИС запрашивает в сервисе ОДЛИ информацию по данной заявке (Order) одним из возможных методов, и по услугам в данной заявке (DiagnosticReport) путем запроса ресурсов. Определяется ссылка на Specimen для требуемого DiagnosticReport.
• после забора биоматериала, когда вся необходимая информация по биоматериалу, включая штрихкод, имеется – МИС обновляет данные по биоматериалу в сервисе ОДЛИ методом PUT Specimen. Параметры ресурса Specimen соответствуют параметрам, описанным в разделе «Передача заявки (POST Bundle заявки)» данного документа.

Ограничения метода:

• метод включается в настройках сервиса, по умолчанию - отключен
• обновление биоматериала возможно только по тем биоматериалам, которые были переданы в сервис без детальной информации (в ресурсе Specimen заполнен только параметр Specimen.subject.reference)
• обновление биоматериала возможно только один раз для конкретного ресурса

Передача результата

Общие положения

Каждый передаваемый результат должен ссылаться на соответствующую заявку.

Допускается:

• передавать результат частями, при этом необходимо указывать для OrderResponse статус “accepted”. При отправлении последней части выполненного результата на заявку необходимо указать статус “completed”, после чего заявка становится помеченная как выполненная, и возможность отправить еще результаты в ответ на данную заявку блокируется
• передавать результат одного исследования как «один DiagnosticReport – множество Observation», так и «множество DiagnosticReport с одним Observation». По первому способу, передаются, к примеру, результаты клинического анализа крови/мочи, по второму – результаты биохимического исследования
• передавать один PDF/xml документ в качестве приложения к нескольким DiagnosticReport, описывающим разные исследования или разные параметры одного исследования
• передавать в результате не те услуги, которые были заказаны в заявке (детально описано ниже)

Не допускается:

• передавать результат как выполненный, если в нем нет ответов на все заказанные в заявке услуги

Полнота ответа на заявку*

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

• учреждение вместо заказанной услуги А выполнило услугу В, при этом такая замена допустима (например, заказана услуга «B03.016.002 Клинический анализ крови», в ответе «B03.016.003 Клинический анализ крови (развернутый)»
• учреждение вместо заказанной услуги А выполнило услугу В, при этом такая замена недопустима (например, заказана услуга «B03.016.003.998 Клинический анализ крови (развернутый) + ретикулоциты», в ответе «B03.016.002.999 Клинический анализ крови (3 показателя)»
• учреждение не выполнило заказанную услугу А и не дала никакой ответ по данному заказу.

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

• если заявка закрывается полностью, или отправляется последняя часть со статусом «completed», то для каждого DiagnosticOrder в заявке должен быть передан DiagnosticReport в ответе. Передача результата со статусом «completed» в том случае, если для одного или нескольких DiagnosticOrder в заявке не передается DiagnosticReport в ответе, недопустима
• если ответ по заявке передается со статусом «final» или «cancelled», то код услуги в DiagnosticReport должен равняться коду услуги в DiagnosticOrder
• если ответ по заявке передается со статусом «corrected», код услуги в DiagnosticReport может отличаться от кода услуги в DiagnosticOrder (в случае, если произошла обоснованная замена услуги результата. Ответственность за такую замену несет целевая МО/КДЛ)
• если ответ по заявке передается со статусом «cancelled», то в DiagnosticReport не передаются поля meta.security.code , result, presentedForm, codedDiagnosis. В поле conclusion указывается причина невыполнения заказанной услуги*

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

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

*Данная проверка включается в настройках сервиса

Передача результатов тестов*

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

• если в сервис передается значение теста, для которого в справочнике тестов указана единица измерения – то значение должно передаваться только как число (valueQuantity), референтные значения должны передаваться только как число (referenceRange.low и/или referenceRange.high).
• если в сервис передается значение теста, для которого в справочнике тестов не указана единица измерения – то значение должно передаваться только как текст (valueString), референтные значения должны передаваться только как текст (referenceRange.text).
• если для теста референтное значение отсутствует или неприменимо, необходимо передавать референтное значение тоже как текст (referenceRange.text), но при этом значение должно быть «нет».

*Данная проверка включается в настройках сервиса

Единицы измерения для тестов*

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

• если в сервис передается значение теста, для которого в справочнике тестов указана единица измерения (или несколько единиц измерения, разделенных точкой с запятой) – то единица измерения, передаваемая в значении (valueQuantity.code) и референтном значении (значениях) (referenceRange.low.code, referenceRange.high.code) должна быть равна единице измерения, указанной для данного теста в справочнике тестов (если единиц измерения в справочнике для данного теста несколько, то любой из указанных для теста единице измерения). Допускается передача результата в сопоставимых единицах измерения – передаваемая е.и. может быть приведена к е.и., указанной в справочнике тестов для данного теста, при помощи правил пересчета, приведенных в справочнике единиц измерения (пример: измерение теста в г/л может передаваться в г/мл, мг/мл, но не может в моль/л). Все передаваемые единицы измерения (valueQuantity.code, referenceRange.low.code, и/или referenceRange.high.code) должны быть одинаковые

*Данная проверка включается в настройках сервиса

Сортировка результатов исследований

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

Пример передачи идентификатора: "identifier":[{"value":"001.001"}]

Один из вариантов – кодировать очередность DiagnosticReport как «ХХХ», а очередность Observation как «ХХХ.УУУ», где ХХХ порядковый номер исследования (DiagnosticReport) в результате, а УУУ порядковый номер теста (Observation) в исследовании.

Бизнес-логика

Передача результата на заявку

Для передачи результата лабораторного исследования используется POST-запрос ресурса Bundle. Ресурс Bundle представляет собой контейнер ресурсов, необходимых для передачи информации о результате. Структура передаваемых данных описана в документе ОИП ДЛИ.

Уникальность результата (ресурса Bundle) определяется по следующим параметрам:

• OrderResponse.identifier.value;
• OrderResponse.identifier.system;
• OrderResponse.identifier.assigner.

При повторном добавлении результата сервис ДЛИ возвращает ошибку: «Повторное добавление результата».

Передача результата без заявки

Для передачи результата лабораторного исследования без заявки используется POST-запрос ресурса Bundle, операция $addresults. Структура передаваемых данных описана в документе Описание Интеграционных Профилей сервиса ДЛИ.

Уникальность результата (ресурса Bundle) определяется по следующим параметрам:

• OrderResponse.identifier.value;
• OrderResponse.identifier.system;
• OrderResponse.identifier.assigner.

При повторном добавлении результата сервис ДЛИ возвращает ошибку: «Повторное добавление результата».

Особенности использования дат в методах $getorder, $getorders, $getresults

В методах $getorder, $getorders, $getresults в качестве входных параметров используются:

1. StartDate – дата начала периода
2. EndDate – дата окончания периода

Датой периода является дата записи заявки/ результата в БД ДЛИ (служебное поле).

Использование даты записи заявки/ результата во входных параметрах позволяет получать данные за запрошенный период только один раз, и не потерять данные во временной шкале.

Пример: при запросе заявок ($getorders) за период 2018-03-15T13:00:00 - 2018-03-15T13:59:59, в ответ будут получены все заявки, переданные в сервис за этот диапазон (с учетом иных параметров запроса). Любые другие заявки, которые будут переданы в сервис позже, уже не будут попадать в данный диапазон дат и для их получения необходимо задавать другой (следующий) интервал.

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

Особенности передачи результатов микробиологических исследований(примеры)

Передача чувствительности к бактериофагам

Вопрос: При передаче бактериологии есть передача чувствительности к антибиотикам, но нет передачи чувствительности к бактериофагам. Как быть в этой ситуации?

Ответ: Фактически – и антибиотики, и бактериофаги являются антибактериальными препаратами, хотя и отличаются по способу действия. В справочнике 1.2.643.2.69.1.1.1.74 «Антибиотики» на данный момент включены и антибиотики, и бактериофаги. Таким образом, передавать чувствительность к бактериофагам следует таким же методом, каким передается чувствительность к антибиотикам в рамках одного DiagnosticReport.

Передача результата анализа "Кал на дисбактериоз"

Вопрос: Есть такой результат анализа "Кал на дисбактериоз", состоящий фактически из нескольких блоков. Как корректно передать результаты по нему?

Ответ: Данный результат можно корректно передать следующим образом:

• антибиотикограмма и чувствительность к бактериофагам передается так, как указано в предыдущем абзаце;
• непосредственно анализ кала на дисбактериоз передается отдельным DiagnosticReport с указанием соответствующего кода услуги результата - A26.05.016 «Исследование микробиоценоза кишечника (дисбактериоз)», при этом в тестах (Observation) данного исследования следует передавать или конкретный микроорганизм по справочнику 1.2.643.5.1.13.13.11.1087, например 5087564 «Enterobacter cloacae», или род микроорганизмов, например 5003371 «Genus Enterobacter».

Передача количества выявленных микроорганизмов

Вопрос: Как при передаче микроорганизмов передать количество выявленных микроорганизмов с указанием единицы измерения?

Ответ: На данный момент сервис позволяет передавать результаты микробиологических исследований как число (valueQuantity) или текст (valueString), или не передавать вовсе.

При передаче результатов как текст в поле valueString следует писать значение с единицами измерения, например «10^5 КОЕ/г», норма также передается текстом, например «10^9 - 10^10 КОЕ/г»

При передаче результатов как число значение результата передается в поле valueQuantity.value, код единицы измерения в поле valueQuantity.code. Единицы измерения необходимо передавать в соответствии со справочником 1.2.643.5.1.13.13.11.1358. На данный момент в этом справочнике предусмотрены несколько значений, пригодных для передачи количества выявленных микроорганизмов, а именно:

Таким образом, результаты должны быть приведены к данным единицам измерения. Например, результат 10^5 может быть представлен как 0,1 млн.КОЕ/г, а результат 10^10 может быть представлен как 10000 млн.КОЕ/г. Норма (если применимо) передается аналогичным способом.

Особенности передачи протоколов лабораторных исследований в формате PDF, заверенных УКЭП

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

Передаваемая УКЭП врача проверяется:

• на соответствие СНИЛС врача, указанного в файле УКЭП, и СНИЛС врача, указанного в DiagnosticReport.performer.reference
• на соответствие ФИО врача, указанного в файле УКЭП, и ФИО врача, указанного в DiagnosticReport.performer.reference

Передаваемая УКЭП МО проверяется:

• на соответствие ОГРН МО, указанного в файле УКЭП, и ОГРН для МО, указанной в OrderResponce.who

Дополнительные проверки:

• передаваемый в бандле ресурс Practitioner должен содержать СНИЛС врача, т.е. должен передаваться параметр identifier с identifier.system = urn:oid:1.2.643.2.69.1.1.1.6.223, при этом identifier.value не должен быть пустым
• если врач передается ссылкой на имеющийся ресурс, то система определяет по ссылке врача и проверяет наличие СНИЛС (параметр identifier с identifier.system = urn:oid:1.2.643.2.69.1.1.1.6.223 должен быть, identifier.value не может быть пустым)
• передаваемый в бандле ресурс Patient должен содержать СНИЛС пациента, т.е. должен передаваться параметр identifier с identifier.system = urn:oid:1.2.643.2.69.1.1.1.6.223, при этом identifier.value не должен быть пустым
• если врач передается ссылкой на имеющийся ресурс, то система определяет по ссылке пациента и проверяет наличие СНИЛС (параметр identifier с identifier.system = urn:oid:1.2.643.2.69.1.1.1.6.223 должен быть, identifier.value не может быть пустым)

В бандле результата результаты исследования могут быть описаны одним или несколькими DiagnosticReport, а также одним или несколькими протоколами в формате PDF/xml, которые также передаются в бандле. Эти исследования могут быть выполнены одним или несколькими врачами. В случае, если DiagnosticReport несколько, и они выполнены разными врачами – протоколы PDF/xml должны быть подписаны этими же врачами, т.е. протокол PDF/xml, указанный для конкретного DiagnosticReport, должен быть подписан именно тем врачом, который указан в DiagnosticReport.performer.

Рассмотрим пример бандла, содержащего четыре DiagnosticReport и два протокола PDF (см. рис.).

Условия:

1. Исследования выполнялись тремя врачами.
2. Первый DiagnosticReport ссылается на протокол 1 и его выполнил врач 1
3. Три остальных DiagnosticReport вместе ссылаются на протокол 2,
4. Каждый DiagnosticReport выполнен своим врачом
   1. DiagnosticReport 2 и 3 выполнили врачи 2 и 3
   2. DiagnosticReport 4 выполнил врач 1.

В данном случае подписи должны быть сформированы следующим образом:

1. Протокол 1 и 2 подписываются врачом 1 -- формируются подписи Pra.Sig 1/1 и Pra.Sig 1/2.
2. Протокол 2 подписывается врачом 2 и врачом 3 -- формируются подписи Pra.Sig 2/2 и Pra.Sig 3/2.
3. И оба протокола подписываются подписью МО -- формируются подписи Org.Sig 1 и Org.Sig 2.

Рисунок 10. Пример бандла, содержащего четыре DiagnosticReport и два протокола PDF

В каждом DiagnosticReport указывается ссылка на врача, выполнившего исследование, ссылка на протокол PDF для данного исследования, а также ссылки на подпись данного протокола данным врачом и на подпись данного протокола подписью МО.

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

1. Берется первый DiagnosticReport из OrderResponse, по ссылкам в DiagnosticReport вычисляются врач, МО, протокол PDF и две подписи (врача и МО).
2. Врач проверяется на наличие СНИЛС. Если СНИЛС врача не указан – возвращается ошибка с указанием ее причины.
3. Подпись врача проверяется на соответствие передаваемому протоколу, а также на соответствие ФИО и СНИЛС врача в структурированных данных и ФИО и СНИЛС врача в подписи врача. Если проверки не выполняются – возвращается ошибка с указанием ее причины.
4. Подпись МО проверяется на соответствие передаваемому протоколу, а также на соответствие ОГРН МО для МО, указанного в структурированных данных, и ОГРН МО в подписи МО. Если проверки не выполняются – возвращается ошибка с указанием ее причины.
5. Шаги 1-4 повторяются для всех DiagnosticReport из OrderResponse.

Правила передачи эпидномера

Эпидномер присваивается организациями, ведущими учет особых заболеваний (Роспотребнадзор, Центры СПИД) и предназначен для однозначной идентификации инфицированного пациента. Эпидномер передается следующим образом:

• если эпидномер известен на момент составления заявки, он должен быть передан в заявке со стороны МИС в параметре Patient.identifier
• если эпидномер присваивается РПН при выполнении исследования, он должен быть передан в результате со стороны ЛИС в параметре DiagnosticReport.identifier. МИС, получившая DiagnosticReport с указанным эпидномером, обязана занести его в систему и передавать в последующих заявках в параметре Patient.identifier

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

Пример передачи эпидномера:

"identifier": [
  {
   "type": {
    "coding": [
     {
      "system": "urn:oid:1.2.643.2.69.1.1.1.122",
      "version": "1",
      "code": "RRI"
     }
    ]
   },
   "system": "urn:oid:1.2.643.5.1.13.2.7.100.6",
   "value": "2128506",
   "assigner": {
    "reference": "Organization/f678d121-5f8e-396d-1942-104cf3d4e81f",
    "display": "Эпидномер"
   }
  }
 ] 

Разбор ситуации по заявкам

В ходе работы с сервисом часто возникает вопрос – была ли заявка передана в сервис, запрашивали ли её, есть ли на нее результат и т.д. Для разбора таких ситуаций необходимо знать: адрес сервиса, авторизационный токен, идентификатор заявки в МИС, GUID направляющей МО. Работа осуществляется с помощью любого REST клиента. GUID направляющей МО можно получить из «Справочника МО» в сервисе Терминологии или при помощи запроса детальной информации по заявке (ниже).

Запрос статуса заявки

Запрос статуса заявки делается запросом вида:

POST http://[base]/exlab/api/fhir/$getstatus?_format=json
authorization: N3 [token]
content-type: application/json
{
 "resourceType": "Parameters",
 "parameter": [
  {
   "name": "SourceCode",
   "valueString": "[Source GUID]"
  },
  {
   "name": "OrderMisID",
   "valueString": "[ID]"
  }
 ]
}

Ответом сервиса является JSON, содержащий статус данной заявки:

{
	"resourceType": "Parameters",
	"parameter": [
	{
		"name": "Status"
		"valueString": "Requested"
	}
  ]
}

Статусы заявки:

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

Определение зоны ответственности

Определение зоны ответственности производится на основании того, какой этап информационного взаимодействия является последним найденным. Примерный алгоритм приведен в таблице.

Получение детальной информации по заявке

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

GET http://[base]/exlab/api/fhir/Order?identifier= [Order MIS ID]
authorization: N3 [token]
content-type: application/json

Ответом сервиса является bundle типа searchset, содержащий информацию по найденным заявкам (Order)

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

{
	"resourceType": "Bundle",
	"type": "searchset"
}

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

"entry": [
 {
	"resource": {
		"resourceType": "Order",
		"id": "f6e80db5-ba47-4436-965e-8e4690eca42c", <--OrderGUID
		"meta": {
			"versionId": "371281c9-8862-4e20-a5fe-c688836ef355",
			"lastUpdated": "2019-01-10T10:38:01" <--Received DateTime
		},
		"identifier": [
		{
			"system": "urn:oid:1.2.643.2.69.1.2.1",
			"value": "254152", <--Order MIS ID
			"assigner": {
				"reference": "Organization/a762831e-dd4c-46be-a329-6dd592a14bb6" <--SourceGUID
			}
		}
	]
  }
 }
]

В данном ответе нас интересуют OrderGUID, SourceGUID, Received DateTime:

• Received DateTime – время, когда заявка была передана в сервис
• OrderGUID – GUID заявки, присвоенный сервисом
• SourceGUID – GUID направляющей МО

На основании этих данных можно сделать запрос статуса заявки или запрос результата

Запрос результата по заявке

Запрос результата по заявке делается запросом вида:

GET http://[base]/exlab/api/fhir/OrderResponse?request=Order/[Order GUID]
authorization: N3 [token]
content-type: application/json

Ответом сервиса является bundle типа searchset, содержащий информацию по результатам (OrderResponse), найденным для указанной в запросе заявки.