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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2. Обмен данными о пациенте

Общая информация о сервисе

Информационный обмен осуществляется в соответствии со стандартом FHIR® (Fast Healthcare Interoperability Resources), разработанным организацией HL7. Подробное описание стандарта доступно по следующим ссылкам:

В качестве протокола взаимодействия используется REST (использование REST-протокола в FHIR® – см. http://fhir-ru.github.io/http.html).

Требования к авторизации

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

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

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

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

Справочники, используемые в сервисе ДЛИ, опубликованы в «Сервисе Терминологии». Описание сервиса Терминологии и правила взаимодействия с ним приведены по ссылке: http://api.netrika.ru/docs.php?article=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 для справочников подсистемы НСИ Регионального фрагмента.

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

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

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

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

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

  1. Передача пациента (POST Patient).
  2. Обновление пациента (PUT Patient).
  3. Добавление полиса пациента (POST Coverage).
  4. Передача заявки (POST Bundle заявки).
  5. Запрос заявки ($getorder).
  6. Передача результата (POST Bundle результата).
  7. Запрос статуса ($getstatus).
  8. Запрос результата ($getresult).
  9. Запрос всех результатов для заданной МО ($getresults).
  10. Запрос ресурсов (GET).
  11. Запрос значений справочника ($expand).
  12. Поиск значения в справочнике ($lookup).
  13. Валидация значения в справочнике ($validate-code).

Список справочников и их значений находится на согласовании.

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

Для регистрации пациента в сервисе ДЛИ используется POST-запрос ресурса Patient. Данные паспорта и СНИЛС пациента передаются в параметре identifier. Полученные данные передаются в ИЭМК.

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

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

Таблица 1. Параметры ресурса Patient

Ресурс Параметр Тип Кратность Описание
1. Patient identifier Identifier 1..* Идентификатор пациента. Указывает код пациента в МИС, ЛИС, его паспортные данные или СНИЛС
1.1. Patient identifier.system uri 1..1 Пространство имён идентификатора. Указывается код:
  • OID передающей системы (для идентификатора в МИС/ЛИС),
  • OID ФМС (1.2.643.5.1.34) для паспорта,
  • OID ПФР (1.2.643.3.9) для СНИЛСа
1.2. Patient identifier.value string 1..1 Значение идентификатора
1.3. Patient identifier.period Period 0..1 Период действия. Указывается для паспорта
1.4. Patient identifier.assigner Organization 1..1 усл Организация, присвоившая идентификатор
  • Для идентификатора пациента в МИС/ЛИС – ссылка на МО,
  • Для других идентификаторов – строка
2. Patient name HumanName 1..1 Информация о ФИО пациента
2.1. Patient name.family string 1..1 Фамилия
2.2. Patient name.given string 1..2 Имя, Отчество. Сначала указывается имя
3. Patient gender code 1..1 Код пола пациента (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.40)
4. Patient birthDate date 1..1 Дата рождения
5. Patient address Address 0..* Информация об адресе пациента
5.1. Patient address.use code 1..1 Тип адреса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.41)
5.2. Patient address.text string 1..1 Адрес строкой

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

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

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

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

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

Пациента можно передать в сервис ДЛИ без информации об адресе, паспорте или полисе. Добавление паспорта и СНИЛС осуществляется путем обновления ресурса Patient. При обновлении данных должна передаваться полная информация о пациенте, т.е. для более корректной работы МИС должна запросить ресурс Patient (операция Get), а потом передать его со всеми параметрами, в том числе и неизменившимися (операция PUT).

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

Параметры ресурса Patient приведены в разделе "Передача пациента (POST Patient)".

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

При обновлении пациента в качестве адреса указывается URL в формате [base]/Patient?_format=json. Объем и структура передаваемых данных аналогичны примеру из раздела "Передача пациента (POST Patient)". При обновлении данных необходимо передавать полностью ресурс Patient, а не только измененные значения.

Добавление полиса пациента (POST Coverage)

Передача полиса пациента осуществляется с помощью ресурса Coverage. Данные полиса указываются в параметре identifier.

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

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

Таблица 2. Параметры ресурса Coverage

Ресурс Параметр Тип Кратность Описание
1. Coverage type Coding 1..1 Тип страхового покрытия:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.48),
  • В параметре version указывается версия справочника в сервисе Терминологии,
В параметре code указывается код значения из справочника
2. Coverage subscriber Patient 1..1 Ссылка. Соотнесение с пациентом
3. Coverage identifier Identifier 1..1 Данные о полисе
3.1. Coverage identifier.system uri 1..1 В качестве кодовой системы указывается строка:
  • 1.2.643.5.1.13.2.1.1.635.[код страховой компании]
3.2. Coverage identifier.value string 1..1
  • [Серия полиса]:[Номер полиса] – при наличии серии
  • [Номер полиса] – когда серия отсутствует
3.3. Coverage identifier.period Period 0..1 Период действия
Пример запроса

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

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

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

Для передачи заявки должен использоваться Bundle (подробно о ресурсе Bundle – см. http://fhir-ru.github.io/bundle.html) типа транзакция. В Bundle должна передаваться следующая информация:

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

Структура Bundle

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

Таблица 3. Описание ресурсов, входящих в состав Bundle

Ресурс Ссылки на другие ресурсы Описание
1. Order
  • Order.subject – ссылка на Patient
  • Order.source – ссылка на Practitioner
  • Order.target – ссылка на Organization
  • Order.detail – ссылка на DiagnosticOrder
В ресурсе указывается общая информация о заявке на проведение исследования:
  • идентификатор и дата заявки,
  • ссылка на врача-автора заявки (Practitioner),
  • ссылка на лабораторию, которая должна выполнить исследование,
  • ссылка на пациента, которому назначено исследование (Patient),
  • ссылка на информацию о назначении (DiagnosticOrder)
2. Patient В ресурсе указывается информация о пациенте. Может не передаваться в Bundle и указываться только ссылка на уже существующий ресурс
3. Practitioner В ресурсе указывается информация о враче: для передачи данных об авторе заявки и врачах, которые сделали назначение пациенту
4. DiagnosticOrder
  • DiagnosticOrder.orderer – ссылка на Practitioner
  • DiagnosticOrder.specimen – ссылка на Specimen
  • DiagnosticOrder. encounter – ссылка на Encounter
  • DiagnosticOrder.supportingInformation – ссылка на Condition/Observation
  • DiagnosticOrder.item.Extension – ссылка на Coverage
В ресурсе указывается следующая информация:
  • назначение (список услуг),
  • ссылка на врача, сделавшего это назначение (Practitioner),
  • ссылка информацию о забранном биоматериале (Specimen),
  • ссылка на информацию о случае обслуживания (Encounter),
  • ссылка на дополнительную информацию о состоянии пациента (Condition/Observation)
  • ссылка на источник финансирования
Если в рамках одной заявки более одного врача назначили пациенту исследования, то по каждому врачу должен быть передан отдельный DiagnosticOrder
5. Specimen В ресурсе указывается информация о забранном биоматериале
6. Encounter Encounter.indication – ссылка на Condition В ресурсе указывается:
  • информация о случае обслуживания, в рамках которого назначено исследование
  • ссылка на информацию о диагнозе пациента
7. Condition В ресурсе указывается информация о состоянии пациента:
  • диагнозы,
  • признак менопаузы
8. Observation В ресурсе указывается информация о состоянии пациента:
  • рост,
  • вес,
  • неделя беременности,
  • день цикла
9. Coverage Coverage.subscriber – ссылка на Patient В ресурсе указывается информация страховке

Схема структуры Bundle приведена на [Рисунок 3].

Рисунок 3. Структура Bundle

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

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

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

Ресурс Кратность Операции Возможность использования ссылки на ресурс
1. Order 1..1 Создание (POST) Всегда должен передаваться ресурс
2. Patient 0..1
  • Создание (POST)
  • Обновление (PUT)
Ресурс может не передаваться, указывается ссылка на уже существующий
3. Practitioner 0..*
  • Создание (POST)
  • Обновление (PUT)
Ресурс может не передаваться, указывается ссылка на уже существующий
4. DiagnosticOrder 1..* Создание (POST) Всегда должен передаваться ресурс
5. Specimen 0..* Создание (POST) Всегда должен передаваться ресурс
6. Encounter 1..1
  • Создание (POST)
  • Обновление (PUT)
Ресурс может не передаваться, указывается ссылка на уже существующий
7. Condition 1..* Создание (POST) Всегда должен передаваться ресурс
8. Observation 0..* Создание (POST) Нельзя указывать ссылку на уже существующий
9. Coverage 0..* Создание (POST) Ресурс может не передаваться, указывается ссылка на уже существующий
Структура запроса Bundle заявки

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

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

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

Общее описание структуры запроса приведено на [Рисунок 4].

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

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

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

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

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

Ресурс Параметр Тип Кратность Описание
1. Order identifier Identifier 1..1 Идентификатор заявки в МИС
2. Order identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы
3. Order identifier.value code 1..1 Идентификатор заявки в МИС
4. Order date dateTime 1..1 Дата заявки
5. Order subject Patient 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
6. Order source Practitioner 1..1 Ссылка. Соотнесение с автором заявки. Должен передаваться ресурс Practitioner в Bundle или указывается ссылка на существующий Practitioner
7. Order target Organization 1..1 Ссылка. Соотнесение с целевой лабораторией. Должна указываться ссылка на существующую в БД Organization
8. Order detail Any 1..* Ссылка. Соотнесение с клинической частью (DiagnosticOrder). Должен передаваться ресурс DiagnosticOrder в Bundle
9. Order when.code CodeableConcept 1..1 Приоритет выполнения (отметка срочности):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.30),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника

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

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

DiagnosticOrder

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

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

Ресурс Параметр Тип Кратность Описание
1. DiagnosticOrder subject Patient 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
2. DiagnosticOrder orderer Practitioner 1..1 Ссылка. Соотнесение с врачом, сделавшем назначение. Должен передаваться ресурс Practitioner в Bundle или указывается ссылка на существующий Practitioner
3. DiagnosticOrder encounter Encounter 1..1 Ссылка. Соотнесение со случаем обслуживания. Должен передаваться ресурс Encounter в Bundle или указывается ссылка на существующий Encounter
4. DiagnosticOrder supportingInformation Observation/ Condition 0..* Ссылка. Соотнесение с описанием состояния пациента (неделя беременности, рост, вес, признак менопаузы и т.п.). Должен передаваться ресурс Observation/ Condition в Bundle
5. DiagnosticOrder specimen Specimen 1..* Ссылка. Соотнесение с биоматериалом. Должен передаваться ресурс Specimen в Bundle
6. DiagnosticOrder status code 1..1 Статус (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.42)
7. DiagnosticOrder item.code CodeableConcept 1..* Код услуги заявки (Номенклатура медицинских услуг):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.31),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
8. DiagnosticOrder item.extension CodeableConcept 1..1 Расширение стандарта для передачи информации об источнике финансирования:
  • В параметре url указывается OID расширения (1.2.643.2.69.1.100.1)
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.32),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
9. DiagnosticOrder item.code.extension.url uri 1..1 Расширение стандарта для передачи информации о полисе):
  • В параметре url указывается OID расширения (1.2.643.2.69.1.100.2)
  • В параметре valueReference должен передаваться ресурс Coverage в Bundle или указывается ссылка на существующий Coverage

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

Specimen

Ресурс Specimen предназначен для передачи информации о забранном биоматериале. Список используемых параметров и их описание приведены в [Таблица 7]. Параметры, которые не используются в информационном обмене, в таблице не указаны.

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

Ресурс Параметр Тип Кратность Описание
1. Specimen type CodeableConcept 0..1 Тип биоматериала:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.33),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
2. Specimen subject Patient 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
3. Specimen collection.comment string 0..1 Комментарий к биоматериалу
4. Specimen collected[x].collectedDateTime dateTime 1..1 Дата-время сбора биоматериала
5. Specimen container.identifier Identifier 0..1 Штрих-код контейнера с биоматериалом
5.1. Specimen container.identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы
5.2. Specimen container.identifier.value code 1..1 Штрих-код
6. Specimen container.type CodeableConcept 0..1 Тип контейнера:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.34),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника

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

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

Encounter

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

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

Ресурс Параметр Тип Кратность Описание
1. Encounter identifier Identifier 1..1 Идентификатор случая обслуживания в МИС
1.1. Encounter identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы
1.2. Encounter identifier.value code 1..1 Идентификатор случая обслуживания в МИС
2. Encounter status code 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.43)
3. Encounter class code 1..1 Тип Encounter (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.44)
4. Encounter type CodeableConcept 1..1 Тип случая обслуживания (региональный справочник типов случая обслуживания):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.35),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
5. Encounter patient Patient 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
6. Encounter reason CodeableConcept 0..1 Цель посещения (региональный справочник целей посещения):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.19),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
7. Encounter indication Any 1..* Ссылка. Соотнесение с диагнозами пациента. Должен передаваться ресурс Condition в Bundle

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

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

Condition

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

  • Диагноз (основной диагноз, сопутствующее заболевание, осложнение);
  • Признак менопаузы.

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

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

Таблица 9. Параметры Condition

Ресурс Параметр Тип Кратность Описание
1. Condition identifier Identifier 0..1 Для основного диагноза требуется указать код МЭС
1.1. Condition identifier.system uri 1..1 В качестве кодовой системы указывается 1.2.643.2.69.1.1.1.61
1.2. Condition identifier.value code 1..1 Код МЭСа
2. Condition subject Patient 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
3. Condition dateAsserted date 0..1 Для диагноза указывается дата установления диагноза
4. Condition code CodeableConcept 1..1 Для диагноза указывается:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.2),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения согласно МКБ-10
Для признака менопаузы указывается:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.39),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
5. Condition category CodeableConcept 1..1 Указание типа Condition:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.36),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
6. Condition clinicalStatus code 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.62)
7. Condition notes string 0..1 Диагноз. Уточнение
8. Condition dueTo.target Condition 0..1 Соотнесение сопутствующего заболевания и осложнения с основным диагнозом. Должен передаваться ресурс Condition в Bundle

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

Observation

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

  • Рост пациента;
  • Вес пациента;
  • Неделя беременности;
  • День цикла.

Содержание ресурса Observation определяется по значению параметра code.

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

Таблица 10. Параметры Observation

Ресурс Параметр Тип Кратность Описание
1. Observation code CodeableConcept 1..1 Указание типа Observation:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.37),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
2. Observation status code 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.47)
3. Observation valueQuantity.value Quantity 1..1 Значение Observation

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

Practitioner

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

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

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

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

Ресурс Параметр Тип Кратность Описание
1. Practitioner identifier Identifier 0..1 Идентификатор врача
1.1. Practitioner identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы
1.2. Practitioner identifier.value code 1..1 Идентификатор врача в МИС
2. Practitioner name HumanName 1..1 ФИО врача
2.1. Practitioner name.family string 1..1 Фамилия
2.2. Practitioner name.given string 1..2 Имя, Отчество. Сначала указывается имя
3. Practitioner organization Organization 1..1 Ссылка. Соотнесение с организацией. Должна указываться ссылка на существующую в БД Organization
4. Practitioner role CodeableConcept 1..1 Код должности врача (Номенклатура должностей медицинских работников и фармацевтических работников):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.2.1.1.607)
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
5. Practitioner specialty CodeableConcept 1..1 Код специальности врача (Номенклатура специальностей специалистов с высшим и послевузовским медицинским и фармацевтическим образованием в сфере здравоохранения):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.2.1.1.181)
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
5.1. Practitioner specialty.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/practitioner-speciality
5.2. Practitioner specialty.Coding.code code 1..1 Код значения из справочника

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

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

Coverage

Ресурс Coverage предназначен для передачи информации о полисах пациента. Параметры ресурса приведены в [Таблица 2] раздела "Добавление полиса пациента (POST Coverage)".

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

Запрос заявки ($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 приведены в [Таблица 12].

Таблица 12. Параметры операции

Имя параметра Описание Кратность Тип Использование
1. SourceCode Код направившей организации (АПУ, стационара). Указывается код из регионального справочника МО 0..1 string in
2. TargetCode Код лаборатории, которая должна выполнить исследование (КДЛ, МЦКДЛ). Указывается код из регионального справочника МО 1..1 string in
3. Barcode Штрих-код контейнера с биоматериалом 0..1 (обязателен один из параметров: Barcode или OrderMisID) string in
4. OrderMisID Идентификатор заявки в МИС 0..1 (обязателен один из параметров: Barcode или OrderMisID) string in
5. Order Заявка 0..* Order out
Пример запроса

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

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

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

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

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

Структура Bundle

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

Таблица 13. Описание ресурсов, входящих в состав Bundle

Ресурс Ссылки на другие ресурсы Описание
1. OrderResponse
  • OrderResponse.request – ссылка на Order,
  • OrderResponse.who – ссылка на Organization,
  • OrderResponse.fulfillment – ссылка на DiagnosticReport
В ресурсе указывается общая информация о результате:
  • идентификатор заказа в ЛИС и дата результата,
  • ссылка на заявку,
  • ссылка на результат по услуге (DiagnosticReport),
  • ссылка на передающую организацию (КДЛ)
2. DiagnosticReport
  • DiagnosticReport.subject – ссылка на Patient,
  • DiagnosticReport.performer– ссылка на Practitioner,
  • DiagnosticReport.requestDetail – ссылка на DiagnosticOrder,
  • DiagnosticReport.result – ссылка на Observation
В ресурсе указывается следующая информация:
  • заключение по услуге,
  • ссылка на назначение (DiagnosticOrder),
  • ссылка на врача, утвердившего результат по услуге (Practitioner),
  • ссылка на пациента (Patient),
  • ссылка на результат теста (Observation)
3. Observation
  • Observation.performer – ссылка на Practitioner
В ресурсе указывается следующая информация:
  • результат теста,
  • ссылка на врача, выполнившего тест (Practitioner)
4. Practitioner В ресурсе указывается информация о враче: для передачи данных о врачах, выполнивших исследование и утвердивших результат

Схема структуры Bundle приведена на [Рисунок 5].

Рисунок 5. Структура Bundle

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

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

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

Ресурс Кратность Операции Возможность использования ссылки на ресурс
1. OrderResponse 1..1 Создание (POST) Всегда должен передаваться ресурс
2. DiagnosticReport 1..* Создание (POST) Всегда должен передаваться ресурс
3. Observation 1..* Создание (POST) Всегда должен передаваться ресурс
4. Practitioner 0..*
  • Создание (POST)
  • Обновление (PUT)
Ресурс может не передаваться, указывается ссылка на уже существующий
Структура запроса Bundle результата

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

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

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

Общее описание структуры запроса приведено на [Рисунок 6].

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

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

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

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

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

Таблица 15. Параметры OrderResponse

Ресурс Параметр Тип Кратность Описание
1. OrderResponse identifier Identifier 1..1 Идентификатор заказа в ЛИС
1.1. OrderResponse identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы
1.2. OrderResponse identifier.value code 1..1 Идентификатор заказа в ЛИС
2. OrderResponse request Order 1..1 Ссылка. Соотнесение с заявкой. Должна указываться ссылка на существующий в БД Order
3. OrderResponse date dateTime 1..1 Дата-время результата
4. OrderResponse who Organization 1..1 Ссылка. Соотнесение с лабораторией. Должна указываться ссылка на существующую в БД Organization
5. OrderResponse orderStatus code 1..1 Статус выполнения заявки (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.45)
6. OrderResponse description string 0..1 Комментарий к результату
7. OrderResponse fulfillment Any 1..* Ссылка. Соотнесение с результатом по услуге. Должен передаваться ресурс DiagnosticReport

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

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

DiagnosticReport

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

Таблица 16. Параметры DiagnosticReport

Ресурс Параметр Тип Кратность Описание
1. DiagnosticReport name CodeableConcept 1..1 Код услуги результата (Номенклатура медицинских услуг):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.31),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
2. DiagnosticReport status code 1..1 В сервисе предполагается получать только утвержденные результаты по услуге (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.46)
3. DiagnosticReport issued dateTime 1..1 Дата-время утверждения результата по услуге
4. DiagnosticReport subject Patient 1..1 Ссылка. Соотнесение с пациентом. Должна указываться ссылка на существующий в БД Patient
5. DiagnosticReport performer Practitioner 1..1 Ссылка. Соотнесение с врачом, утвердившим результат. Должен передаваться ресурс Practitioner в Bundle или указывается ссылка на существующий Practitioner
6. DiagnosticReport requestDetail DiagnosticOrder 1..1 Ссылка. Соотнесение с назначением (DiagnosticOrder). Должна указываться ссылка на существующий в БД DiagnosticOrder
7. DiagnosticReport result Observation 1..* Ссылка. Соотнесение с результатом теста. Должен передаваться ресурс Observation
8. DiagnosticReport conclusion string 1..1 Текст заключения по услуге
9. DiagnosticReport presentedForm Attachment 1..1 Электронная версия документа с результатом по услуге
9.1. DiagnosticReport presentedForm.data base64Binary 1..1 Преобразованный в base64-строку json следующей структуры:
{
"data": "[данные]",
"public_key": "[публичный ключ Gost3410]",
"hash": "[хэш Gost3411]",
"sign": "[подпись хэша Gost3410]"
}

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

Observation

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

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

Таблица 17. Параметры Observation

Ресурс Параметр Тип Кратность Описание
1. Observation code CodeableConcept 1..1 Код теста, для которого передается результат в Observation (региональный справочник тестов):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.1),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
2. Observation comments string 0..1 Комментарий к результату теста
3. Observation issued instant 1..1 Дата-время результата теста
4. Observation status code 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.47)
5. Observation method CodeableConcept 0..1 Методика исследования:
  • В параметре system указывается OID передающей системы
  • В параметре code указывается наименование методики
6. Observation performer Practitioner 1..1 Ссылка. Соотнесение с врачом-исполнителем. Должен передаваться ресурс Practitioner в Bundle или указываться ссылка на существующий Practitioner
7. Observation value[x] valueQuantity/ valueCodeableConcept/ valueString/ valueRange/ valueRatio/ valueSampledData/ valueAttachment/ valueTime/ valueDateTime/ valuePeriod 1..1 усл Должно передаваться или value[x] или dataAbsentReason Результат теста. Единицы измерения. Результат теста. Числовой результат. Должно передаваться или valueQuantity или valueString
8. Observation dataAbsentReason CodeableConcept 1..1 усл Должно передаваться или value[x] или dataAbsentReason Причина, по которой результат отсутствует:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.38),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
9. Observation referenceRange low, high, meaning, age, text 1..1 усл Должен иметь хотя бы нижнее (элемент low), либо верхнее (элемент high) значение, либо элемент text Рефферентные значения для полученного результата

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

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

Practitioner

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

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

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

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

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

Для обращения к операции необходимо указывать ее URL в формате [base]/$[имя операции].

Операция возвращает статус заявки, соответствующей условиям поиска.

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

Входные и выходные параметры операции getstatus приведены в [Таблица 18].

Таблица 18. Параметры операции

Имя параметра Описание Кратность Тип Использование
1. SourceCode Код направившей организации (АПУ, стационара). Указывается код из регионального справочника МО 1..1 усл (указывается или OrderId или SourceCode + OrderMisID) string in
2. OrderMisID Идентификатор заявки в МИС 1..1 усл (указывается или OrderId или SourceCode + OrderMisID) string in
3. OrderId Идентификатор заявки в сервисе ДЛИ 1..1 усл (указывается или OrderId или SourceCode + OrderMisID) string in
4. Status Статус заявки 1..1 string out
Пример запроса

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

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

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

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

Для обращения к операции необходимо указывать ее URL в формате [base]/$[имя операции].

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

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

Входные и выходные параметры операции getresult приведены в [Таблица 19].

Таблица 19. Параметры операции

Имя параметра Описание Кратность Тип Использование
1. SourceCode Код направившей организации (АПУ, стационара). Указывается код из регионального справочника МО 1..1 string in
2. TargetCode Код лаборатории, которая должна выполнить исследование (КДЛ, МЦКДЛ). Указывается код из регионального справочника МО 1..1 string in
3. OrderMisID Идентификатор заявки в МИС 1..1 string in
4. OrderResponse Результат 0..* OrderResponse out
Пример запроса

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

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

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

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

Для обращения к операции необходимо указывать ее URL в формате [base]/$[имя операции].

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

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

Входные и выходные параметры операции getresults приведены в [Таблица 20].

Таблица 20. Параметры операции

Имя параметра Описание Кратность Тип Использование
1. SourceCode Код направившей организации (АПУ, стационара). Указывается код из регионального справочника МО 1..1 string in
2. TargetCode Код лаборатории, которая должна выполнить исследование (КДЛ, МЦКДЛ). Указывается код из регионального справочника МО 0..1 string in
3. StartDate Диапазон поиска результатов (дата результата). Дата начала 1..1 datetime in
4. EndDate Диапазон поиска результатов (дата результата). Дата окончания 0..1 datetime in
5. OrderResponse Результат 0..* OrderResponse out
Пример запроса

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

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

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

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

[base]/DiagnosticOrder/2c98670c-3494-4c63-bb29-71acd486da3d?_format=json