VK
Youtube
Telegram
+7(812) 670-45-63

Сервис обмена данными лабораторных исследований

Сервис предназначен для автоматизации процесса передачи направлений на лабораторные исследования в ЛИС и последующего получения результатов

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

Процесс проведения лабораторных исследований согласно ГОСТ Р 53022.1-2008 состоит из трех этапов:
  1. Преаналитический. К преаналитическому этапу относятся процессы по подготовке заявки на выполнение исследования, передаче заявки и биоматериала в КДЛ, подготовке к выполнению исследования. Состоит из двух фаз:
  2. Внелабораторная фаза. Включает в себя:
  3. Формирование направления. Выполняется врачом МО в случае необходимости проведения исследования.
  4. Сбор биоматериала. Осуществляет медицинская сестра процедурного кабинета в соответствии с данными направления.
  5. Формирование заявки. К направлению добавляется необходимая дополнительная информация согласно требованиям лаборатории.
  6. Передача заявки и биоматериала в лабораторию.
  7. Внутрилабораторная фаза. Включает в себя:
  8. Проверка корректности заявки. Выполняется регистратором.
  9. Формирование/изменение заказа (заказ может быть передан в ЛИС из МИС автоматически или внесен в ЛИС сотрудником МО через удаленное рабочее место). Выполняется регистратором/врачом клинической лабораторной диагностики.
  10. Аналитический. К аналитическому этапу относится процесс выполнения исследования. Проведение исследования выполняется врачом клинической лабораторной диагностики вручную или с помощью оборудования.
  11. Постаналитический. К постаналитическому этапу относятся процессы по утверждению результата, передаче утвержденного результата в МО. Проверка корректности полученных результатов (анализ результатов) выполняется врачом клинической лабораторной диагностики. В случае необходимости производится корректировка заказа и выполнение дополнительных исследований. После подтверждения результаты передаются в МО.
Информационное обеспечение процесса осуществляют: МИС МО (как источник информации о назначении и получатель результатов исследования), ЛИС КДЛ (как получатель информации о назначении и источник результатов исследований) и сервис ДЛИ (как информационная шина, обеспечивающая информационный обмен и как региональное хранилище информации по лабораторным исследованиям).

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

Сервис ДЛИ предназначен для ведения, хранения, поиска и выдачи сведений по лабораторным исследованиям в рамках региона. Сервис обеспечивает:
  1. Централизованный учет заявок на лабораторное исследование.
  2. Централизованный учет результатов лабораторных исследований.
  3. Учет информации о пациентах, которым назначено лабораторное исследование.
  4. Учет информации о медперсонале.
  5. Получение заявок на лабораторное исследование и передача их по запросу.
  6. Передача статуса заявки по запросу.
  7. Получение результатов лабораторных исследований и передача их по запросу.
  8. Передача всех результатов лабораторных исследований для МО по запросу.
Базовая схема информационного взаимодействия приведена на [Рисунок 1].
Обмен данными между МИС МО, ЛИС КДЛ и сервиса ДЛИ осуществляется в рамках следующих сценариев:
  1. Добавление заявки. Заявка передается из МИС.
  2. Запрос заявки. Заявка не передается в ЛИС автоматически. ЛИС КДЛ запрашивает заявку у сервиса ДЛИ при поступлении биоматериала в лабораторию.
  3. 3. Добавление результата. Результат передается из ЛИС. В сервис ДЛИ должны передаваться только утвержденные результаты исследований.
  4. Запрос статуса заявки. Информация об изменении статуса заявки не передается в МИС автоматически. МИС МО запрашивает статус заявки у сервиса ДЛИ
  5. Запрос результата. Результат не передается в МИС автоматически. МИС МО запрашивает заявку у сервиса ДЛИ.
Описание протокола и запросов приведено в разделе "Описание протокола взаимодействия".

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

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

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

Общая информация о сервисе
Информационный обмен осуществляется в соответствии со стандартом FHIR® (Fast Healthcare Interoperability Resources), разработанным организацией HL7. Используемая версия FHIR DSTU2, 1.0.2. Подробное описание стандарта доступно по следующим ссылкам:
В качестве протокола взаимодействия используется REST (использование REST-протокола в FHIR® – см. http://fhir-ru.github.io/http.html).
Требования к авторизации
Для передачи данных в сервис ДЛИ необходимо передавать в заголовке сообщения авторизационный токен в формате:
Authorization: N3[пробел][GUID передающей системы]
GUID передающей системы выдается разработчику МИС администратором интеграционной платформы. GUID передающей системы должен соответствовать идентификатору информационной системы, указанному в идентификаторе заявки или результата.
Использование справочников
Справочники, используемые в сервисе ДЛИ, опубликованы в «Сервисе Терминологии». Описание сервиса Терминологии и правила взаимодействия с ним приведены по ссылке: https://n3health.ru/terminology
Для каждого справочника в Настоящем документе указан его 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) то учреждение или подразделение (если зарегистрировано в справочнике), где проходит лечение пациент (открыт случай обслуживания и создана заявка).
Формат даты
Значения параметров методов, имеющих тип Datetime, необходимо передавать в формате UTC или с указанием таймзоны. Если таймзона не указана, то в рамках сервиса считается, что передано локальное время (региональное), и сервис работает с переданным значением как с "датой, для которой не указана таймзона".

Пример времени по Москве: 2021-01-18T12:20:12.2508719+03:00

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

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

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

0..1 - параметр необязательный, максимальное количество экземпляров один;
0..* – параметр необязательный, максимальное количество экземпляров не ограничено;
1..1 – параметр обязательный, экземпляр один;
1..2 – параметр обязательный, экземпляр один или два;
1..* – параметр обязательный, максимальное количество экземпляров не ограничено
Передача пациента (POST Patient)
Для регистрации пациента в сервисе ДЛИ используется POST-запрос ресурса Patient. Данные ДУЛ, полиса и СНИЛС пациента передаются в параметре identifier.
При передаче данных анонимных пациентов следует в ресурсе Patient передавать параметр name.use = “anonimous”.

Уникальность пациента проверяется по совокупности параметров ID МИС и ИД пациента в МИС. Многократная передача одного и того же пациента из одной и той же МИС с разными идентификаторами МИС не допускается.

Описание параметров
Перечень параметров и их описание представлено в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Помимо перечисленных выше параметров, в сервис может быть передан дополнительный идентификатор прикрепления (OID (1.2.643.5.1.13.2.7.100.5)). Особенности передачи идентификатора прикрепления описаны ниже.
Идентификатор является разновидностью уже имеющегося идентификатора Patient.identifier и имеет пространство имен 1.2.643.5.1.13.2.7.100.9. В ресурсе Patient допускается передавать несколько identifier из пространства имен 1.2.643.5.1.13.2.7.100.9.

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

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

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

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

Пример запроса
МИС должна запросить ресурс Patient (операция GET)
GET
http://b2b.n3health.ru/exlab/api/fhir/Patient/aba1a1c6-1476-4f80-bf3f-d75c0325bfe1
authorization: N3[пробел][GUID передающей системы]
content-type: application/json
При обновлении пациента в качестве адреса указывается URL в формате [base]/Patient/[GUID]?_format=json. GUID пациента в URL должен соответствовать id, указанному в запросе. При обновлении данных необходимо передавать полностью ресурс Patient, а не только измененные значения.

Пример запроса приведен в разделе "Примеры запросов".
Передача врача (POST Practitioner)
Для регистрации врача в сервисе ДЛИ используется POST-запрос ресурса Practitioner. Данные СНИЛСа, идентификатор в ИС врача передаются в параметре identifier.

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

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

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

Список обязательных ресурсов и допустимые операции над ресурсами Bundle приведены в таблице ниже.
Структура запроса Bundle заявки
При добавлении заявки в качестве адреса указывается URL в формате [base]?_format=json. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ДЛИ.
Json-запрос для передачи заявки содержит следующие компоненты:
  • Указание, что в запросе передается Bundle,
  • Метаинформация,
  • Тип Bundle,
  • Данные о передаваемых ресурсах:
  • Сам ресурс,
  • Операция над этим ресурсом.
Общее описание структуры запроса приведено на рисунке ниже.
Пример базовой структуры json-запроса для передачи заявки приведен в разделе "Примеры запросов".

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

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

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

Ресурс Specimen предназначен для передачи информации о забранном биоматериале. Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
OID передающих систем приведен в справочнике "Участники информационного обмена N3.Здравоохранение". Справочник опубликован в сервисе Терминологии с OID 1.2.643.2.69.1.2
Пример фрагмента Bundle для Specimen приведен в разделе "Примеры запросов".

Encounter
Ресурс Encounter предназначен для передачи информации о случае обслуживания и ссылок на диагнозы пациента. Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
OID передающих систем приведен в справочнике "Участники информационного обмена N3.Здравоохранение". Справочник опубликован в сервисе Терминологии с OID 1.2.643.2.69.1.2
Пример фрагмента Bundle для Encounter приведен в разделе "Примеры запросов".

Condition
Ресурс Condition предназначен для передачи информации о состоянии пациента. Содержание ресурса Condition определяется по значению параметра category:
  • Для диагноза category = diagnosis.
  • Для признака менопаузы category = finding.
Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
Пример фрагмента Bundle для Condition приведен в разделе "Примеры запросов".

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

Practitioner
Ресурс Practitioner предназначен для передачи информации о враче. В этом ресурсе указывается:
  • Врач, сделавший назначение;
  • Врач-автор заявки.
Перечень параметров и их описание представлены в разделе «Передача врача».
Запрос заявки ($getorder)
Получение информации о заявке может осуществляться двумя способами: с помощью запроса ресурса Order или с помощью дополнительной операции getorder.
Для обращения к операции необходимо указывать ее URL в формате [base]/$[имя операции].
Более подробно о Custom Operation можно посмотреть по адресу (начиная с п. 2.2.0.2 Implementations Defined Operations): http://fhir-ru.github.io/operations.html

Операция getorder возвращает список ресурсов Order, удовлетворяющих условиям поиска. Ресурсы, на которые имеются ссылки в Order, будут возвращаться запрашивающей системе с помощью функционала получения ресурса (GET с указанием ссылки на запрашиваемый ресурс).

Описание параметров
Входные и выходные параметры операции getorder приведены в таблице ниже.
Пример запроса
При поиске заявки в качестве адреса указывается URL в формате [base]/$getorder?_format=json. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.
Пример запроса приведен в разделе "Примеры запросов".
Запрос заявок ($getorders)
Операция getorders возвращает ссылки на ресурсы Order, удовлетворяющие условиям поиска. Ресурсы, на которые имеются ссылки в Order, будут возвращаться запрашивающей системе с помощью функционала получения ресурса (GET с указанием ссылки на запрашиваемый ресурс).

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

Описание параметров
Входные и выходные параметры операции getorders приведены в таблице ниже.
Пример запроса
При поиске заявки в качестве адреса указывается URL в формате [base]/$getorders?_format=json. В ответе сервис возвращает json с массивом Order, найденных в сервисе ДЛИ.
Передача результата (POST Bundle результата)
Для передачи результата должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:
  • Ответ на заявку.
  • Общие сведения о результате (идентификатор, дата и т.п.).
  • Информация о враче, выполнившем исследование и утвердившем результат.
  • Результаты тестов
  • Сведения об использованном оборудовании
  • Печатная форма протокола исследования в формате PDF

Структура Bundle
Bundle используется для передачи набора ресурсов. Для каждого из ресурсов Bundle должна указываться операция (POST, PUT). Перечень ресурсов и их описание представлено в таблице ниже.
Схема структуры Bundle приведена на [Рисунок 5].
Допустимые операции над ресурсами Bundle
Список обязательных ресурсов и допустимые операции над ресурсами Bundle приведены в таблице ниже.
Структура запроса Bundle результата
При добавлении результата в качестве адреса указывается URL в формате [base]?_format=json. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ДЛИ.
Json-запрос для передачи результата содержит следующие компоненты:
  • Указание, что в запросе передается Bundle,
  • Метаинформация,
  • Тип Bundle,
  • Данные о передаваемых ресурсах:
  • Сам ресурс,
  • Операция над этим ресурсом.
Общее описание структуры запроса приведено на рисунке ниже.
Описание ресурсов, входящих в состав Bundle
OrderResponse
Ресурс OrderResponse предназначен для передачи общей информации о результате исследований. Передача результата по частям предполагает передачу каждый раз нового OrderResponse, а не обновление ранее переданного.

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

OID передающих систем приведен в справочнике "Участники информационного обмена N3.Здравоохранение". Справочник опубликован в сервисе Терминологии с OID 1.2.643.2.69.1.2

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

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

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

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

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

Передача информации о выявлении роста или об отсутствии роста для конкретного микроорганизма осуществляется путем передачи значения в поле interpretation – DET (Обнаружено) и ND (Не обнаружено) соответственно. При наличии может быть передан количественный (например, количество выявленных бактерий) или текстовый (например, «Нет в поле зрения») результат.

Передача информации о чувствительности к тому или иному антибиотику для конкретного микроорганизма осуществляется путем передачи значения в поле interpretation. Рекомендуемые значения: R (Устойчивый), S (Чувствительный), I (Умеренно-устойчивый).
Передача информации об отсутствии роста микрофлоры осуществляется путем передачи ресурса Observation с system = 1.2.643.2.69.1.1.1.94, типа не выявленной микрофлоры в поле code, и значения ND (Не обнаружено) в поле interpretation.
Примеры базовых структур json-запроса для передачи результата по микробиологии приведены в разделе "Примеры запросов".

Practitioner
Ресурс Practitioner предназначен для передачи информации о враче. В этом ресурсе указывается:
  • Врач, выполнивший тест;
  • Врач, утвердивший результат тестов услуги.
Пример фрагмента Bundle для Practitioner приведен в разделе "Примеры запросов".

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

Для передачи результата без заявки должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:
  • Общие сведения о заявке (отправитель, получатель)
  • Информация о биоматериале
  • Общие сведения о результате (идентификатор, дата и т.п.)
  • Информация о пациенте
  • Информация о враче, выполнившем исследование и утвердившем результат.
  • Значение результата.
Отличие от аналогичного Bundle результата следующие:
  • В Bundle включены ресурсы Order, Specimen, Patient;
  • Вместо внешних ссылок на ресурсы Bundle заявки используется внутренние ссылки на ресурсы Order, Specimen, Patient
  • В ресурсе DiagnosticReport передается ссылка на ресурсы Specimen, входящие в данный Bundle
Схема структуры Bundle приведена на рисунке ниже.
Допустимые операции над ресурсами Bundle
Список обязательных ресурсов и допустимые операции над ресурсами Bundle приведены в таблице ниже.
Структура запроса Bundle результата без заявки
При добавлении результата в качестве адреса указывается URL в формате [base]/$addresults?_format=json. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ДЛИ.
Json-запрос для передачи результата содержит следующие компоненты:
  • Указание, что в запросе передается Bundle,
  • Метаинформация,
  • Тип Bundle,
  • Данные о передаваемых ресурсах:
  • - Сам ресурс,
  • - Операция над этим ресурсом.
Общее описание структуры запроса приведено на рисунке ниже.
Примеры базовой структуры json-запроса для передачи результата без заявки приведены в разделе «Примеры запросов».

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

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

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

Пример запроса приведен в разделе "Примеры запросов".
Запрос результата ($getresult)
Получение информации о результате выполненного исследования может осуществляться двумя способами: с помощью запроса ресурса OrderResponse или с помощью дополнительной операции getresult. Для обращения к операции необходимо указывать ее URL в формате [base]/$[имя операции].

Операция возвращает список ресурсов OrderResponse, удовлетворяющих условиям поиска. Ресурсы, на которые имеются ссылки в OrderResponse, будут возвращаться запрашивающей системе с помощью функционала получения ресурса (GET с указанием ссылки на запрашиваемый ресурс).

Описание параметров
Входные и выходные параметры операции getresult приведены в таблице ниже.
Пример запроса
При поиске результатов выполненных исследований в качестве адреса указывается URL в формате [base]/$getresult?_format=json. В ответе сервис возвращает json с массивом OrderResponse, найденных в сервисе ДЛИ.
Пример запроса приведен в разделе "Примеры запросов".
Запрос всех результатов для заданной МО ($getresults)
Получение информации о результатах выполненных исследований по заявкам заданной организации осуществляется с помощью дополнительной операции getresults.

Для обращения к операции необходимо указывать ее URL в формате [base]/$[имя операции].
Операция возвращает список ресурсов OrderResponse, удовлетворяющих условиям поиска. Ресурсы, на которые имеются ссылки в OrderResponse, будут возвращаться запрашивающей системе с помощью функционала получения ресурса (GET с указанием ссылки на запрашиваемый ресурс).

Описание параметров
Входные и выходные параметры операции getresults приведены в таблице ниже.
Пример запроса
При поиске результатов выполненных исследований в качестве адреса указывается 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.
Ограничения метода:
  • сервис ОДЛИ пассивный, т.е. он только получает информацию от участников информационного взаимодействия. Сервис ОДЛИ не может информировать ЛИС о том, что заявка отменена. Информирование контрагента в таком случае должно решаться иными способами.
  • отмена заявки на исследование не может быть произведено после того, как заявка запрошена из ЛИС или по ней переданы результаты.
  • отмена возможна только отправителем заявки. Авторизационный токен, используемый при отмене, должен совпадать с токеном, использованным при передаче.
Описание параметров
Входные параметры операции cancelorder приведены в таблице ниже.
Выходным параметром является JSON вида {"resourceType":"Parameters", "parameter":[Х]}, где Х – это массив ресурсов, отмененных в ходе запроса. В параметре 79 "name" передается ссылка на ресурс, в параметре "valueString" статус операции: "True", означающий успешную отмену ресурса.

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

При отмене заявки сервис ОДЛИ помечает результат и все входящие в него ресурсы как отмененные. Такой результат более не может быть запрошена в сервисе методами запроса результата. Возможна повторная передача результата с таким же OrderMISID.
Ограничения метода:
  • сервис ОДЛИ пассивный, т.е. он только получает информацию от участников информационного взаимодействия. Сервис ОДЛИ не может информировать МИС о том, что результат отменен. Информирование контрагента в таком случае должно решаться иными способами.
  • при отмене результата он не может быть отозван из федеральных сервисов (СЭМД, РЭМД и др.)
  • отмена возможна только отправителем результата. Авторизационный токен, используемый при отмене, должен совпадать с токеном, использованным при передаче.
Описание параметров
Входные параметры операции 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 приведены в таблице ниже.
Выходным параметром является 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 необходимо передать со всеми параметрами, в том числе и неизменившимися. Обновление ресурса разрешено только отправителям данного ресурса.
Для деактивации услуги следует пользоваться параметром «Дата окончания действия». Принимающая информационная система должна корректно обрабатывать данный параметр.

Описание параметров
Перечень параметров и их описание представлены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.
* Обязательно передается один код услуги, может передаваться один или несколько кодов тестов.
** Даты начала и окончания действия указываются «включительно», т.е. услуга с периодом действия 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, удовлетворяющих условиям запроса.

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

Для корректной работы подсистемы ОДЛИ смежные инфосистемы должны поддерживать методы сервиса Терминологии. Актуальная информация по работе с сервисом Терминологии находится по адресу Терминология.
Должны поддерживаться следующие методы:
  • Запрос справочника
  • Запрос списка версий справочника
  • Запрос значений справочника ($expand)
  • Поиск значения в справочнике ($lookup)
  • Валидация значения в справочнике ($validate-code)
Запрос справочника
Получение информации о справочнике осуществляется с помощью GET-запроса. В качестве адреса должен быть указан URL в формате [base]/ValueSet?_format=json&url=urn:oid:[OID справочника].
Пример запроса:
GET [base]/ValueSet?_format=json&url=urn:oid:1.2.643.2.69.1.1.1.64
Запрос списка версий справочника
Получение информации о списке версий справочника осуществляется с помощью GET-запроса. В качестве адреса должен быть указан URL в формате [base]/ValueSet/[идентификатор справочника в сервисе Терминологии]/$versions?_format=json.

Пример запроса:
GET [base]/ValueSet/1.2.643.2.69.1.1.1.64/$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. Направить на адрес электронной почты СТП заявку на подключение к региональному тестовому стенду требуемого сервиса. На каждый сервис подается отдельная заявка, которая должна содержать следующие данные:
  • Наименование компании разработчика ЛИС/МИС/РИС/РМИС с указанием формы собственности;
  • Наименование ЛИС/МИС/РИС/РМИС;
  • Роли, выполняемые ЛИС/МИС/РИС/РМИС в сервисе (передача заявок, результатов, рецептов и др.);
  • Контактные данные ответственного за интеграцию сотрудника (ФИО, почта, телефон).
  1. Ответ СТП будет содержать:
  • Ссылки на тестовый сервис и НСИ (справочники, используемые при обмене данными);
  • Ссылка на документ «Описание интеграционных профилей»;
  • Реквизиты доступа к сервису (авторизационный токен, OID).
  1. Если в МО принято решение о передаче PDF протоколов с УКЭП, дополнительно должны быть предоставлены:
  • Корневые сертификаты удостоверяющих центров (УЦ), чьи подписи используются для работы с сервисом;
  • Сертификаты промежуточных УЦ, если таковые используются в УЦ, чьи подписи используются для работы с сервисом;
  • Списки отзыва (ссылки на них в сети интернет) сертификатов всех УЦ, чьи подписи используются для работы с сервисом;
  • Образец протокола PDF и открепленные подписи к нему в виде файлов.
  1. Для получения консультаций в процессе работы с сервисом следует отправлять запросы на адрес электронной почты СТП. Запрос на консультацию должен содержать:
  • Наименование сервиса;
  • Тип площадки (тестовая, продуктивная);
  • URL куда отправляется запрос;
  • Тип запроса (POST или GET);
  • Авторизационный токен, указываемый в запросе;
  • Лог в *txt запроса к сервису и ответа сервиса на запрос;
  • Идентификатор N3RID, полученный в ответе сервиса;
  • Сам вопрос по работе сервиса.
  1. Завершив работы по интеграции с тестовым стендом, передать в тестовый стенд корректные примеры запросов. Запросы по передаче тестового пациента должны включать как минимум данные по ФИО, полу, ДР пациента, данные полиса ОМС и СНИЛС. Запросы по передаче тестового врача должны включать как минимум данные по ФИО, должности, специальности врача, данные СНИЛС.
ОДЛИ

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

Тестовые заявки на инструментальные исследования должны удовлетворять следующим требованиями:
  • Вид оплаты ОМС;
  • Наличие данных пациента (рост, вес) в заявке.
Тестовые результаты инструментальных исследований должны удовлетворять следующим требованиями:
  • Если есть возможность передачи данных изображения с возможностью просмотра через viewer - должны быть переданы описание, заключение в структурированном виде, протокол PDF, данные о снимке.
  • Если возможность передачи данных изображения с возможностью просмотра через viewer отсутствует - должны быть переданы описание, заключение в структурированном виде, протокол PDF.
  • Если в регионе принято решение о передаче PDF протоколов в федеральный сервис РЭМД, примеры должны содержать протоколы, подписанные согласно требованиям документации.
ОДР

Тестовые рецепты должны удовлетворять следующим требованиями:
  • переданы все виды рецептов, формируемые в МО;
  • бланк рецепта в PDF подписан согласно требованиям документации.

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

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

Общие сведения
Использование справочника организаций
При работе с сервисом необходимо корректно заполнять данные организаций – направляющей, целевой и др. При этом, если на уровне региона справочник организаций ведется в древовидном виде с разделением на отделения и подразделения, необходимо всю информацию передавать детализированно, от имени конкретного отделения и подразделения. Передача информации от имени головной МО в данном случае недопустима.
В случае распределенной работы учреждения (бизнес-процесс лечения и исследования распределен на несколько подразделений и отделений) следует пользоваться следующими правилами: Если пациент числится в отделении А, лечится в отделении Б, заявку ему делают в подразделении В, врач работает в подразделении Г, а забор материала делается в подразделении Д, то:
  • идентификатор МО в случае лечения (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,
  1. то происходит ОБНОВЛЕНИЕ ресурса операция PUT;
  2. Если изменения в параметрах, по которым определяется уникальность ресурса:
  • identifier.assigner (где identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5),
  • identifier.value,
  • identifier.assigner,
  1. то возвращается ошибка;
Обновление ресурса разрешено ТОЛЬКО отправителям данного ресурса. В случае попытки изменения ресурса, заведенного другим ЛПУ или другой ИС, сервис возвратит ошибку: "Доступ редактирования для данного 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,
  1. то происходит ОБНОВЛЕНИЕ ресурса операция PUT;
  2. Если изменения в следующих параметрах:
  • identifier.assigner (где identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5),
  • identifier.value,
  • practitionerRole.managingOrganization,
  1. то возвращается ошибка;
Обновление ресурса разрешено ТОЛЬКО отправителям данного ресурса. В случае попытки изменения ресурса, заведенного другим ЛПУ или другой ИС, сервис возвратит ошибку: "Доступ редактирования для данного 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 документ в качестве приложения к нескольким 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, которые также передаются в бандле. Эти исследования могут быть выполнены одним или несколькими врачами. В случае, если DiagnosticReport несколько, и они выполнены разными врачами – протоколы PDF должны быть подписаны этими же врачами, т.е. протокол PDF, указанный для конкретного DiagnosticReport, должен быть подписан именно тем врачом, который указан в DiagnosticReport.performer.

Рассмотрим пример бандла, содержащего четыре DiagnosticReport и два протокола PDF (см. рис.).
Условия:
  1. Исследования выполнялись тремя врачами.
  2. Первый DiagnosticReport ссылается на протокол 1 и его выполнил врач 1
  3. Три остальных DiagnosticReport вместе ссылаются на протокол 2,
  4. Каждый DiagnosticReport выполнен своим врачом
  5. DiagnosticReport 2 и 3 выполнили врачи 2 и 3
  6. 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.
В каждом 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), найденным для указанной в запросе заявки.