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

Процесс проведения лабораторных исследований согласно ГОСТ Р 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).

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

  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 Пространство имён идентификатора. Указывается код:
  • http://netrika.ru/patient-mis-identifier для идентификатора пациента в МИС/ЛИС,
  • http://netrika.ru/patient-pasport для паспорта,
  • http://netrika.ru/patient-snils для СНИЛСа
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)
4. Patient birthDate date 1..1 Дата рождения
5. Patient address Address 0..* Информация об адресе пациента
5.1. Patient address.use code 1..1 Тип адреса (справочник FHIR)
5.2. Patient address.text string 1..1 Адрес строкой
Пример запроса

При добавлении нового пациента в качестве адреса указывается 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 Тип страхового покрытия
2. Coverage subscriber Patient 1..1 Ссылка. Соотнесение с пациентом
3. Coverage identifier Identifier 1..1 Данные о полисе
3.1. Coverage identifier.system uri 1..1 Пространство имён идентификатора. Указывается код для:
  • http://netrika.ru/polis-oms-old для полиса ОМС старого образца,
  • http://netrika.ru/polis-oms-new для полиса ОМС единого образца,
  • http://netrika.ru/polis-dms для полиса ДМС
3.2. Coverage identifier.value string 1..1 Значение идентификатора
3.3. Coverage identifier.period Period 0..1 Период действия
3.4. Coverage identifier.assigner Organization 1..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.4),
    • Операция над этим ресурсом.

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

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

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

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

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

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

Ресурс Параметр Тип Кратность Описание
1. Order identifier Identifier 1..1 Идентификатор заявки в МИС
2. Order identifier.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/mis-identifier
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 Приоритет выполнения (отметка срочности. На момент написания документа региональный справочник отсутствует)
9.1. Order when.code.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/priority
9.2. Order when.code.Coding.code code 1..1 Код значения из справочника

Пример фрагмента 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)
7. DiagnosticOrder item.code CodeableConcept 1..* Код услуги заявки (Номенклатура медицинских услуг, 1.2.643.5.1.13.2.1.1.473)
8. DiagnosticOrder item.code.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/diagnostic-order-code
9. DiagnosticOrder item.code.Coding.code code 1..1 Код значения из справочника
10. DiagnosticOrder item.extension CodeableConcept 1..1 Источник финансирования
10.1. DiagnosticOrder item.code.extension.url uri 1..1 Указывается тип расширения (данные об источнике финансирования.На момент написания документа справочник отсутствует): http://netrika.ru/diagnostic-order-financial-extension
10.2. DiagnosticOrder item.code.extension.coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/financial
10.3. DiagnosticOrder item.code.extension.coding.code code 1..1 Код значения из справочника
10.4. DiagnosticOrder item.code.extension.url uri 1..1 Указывается тип расширения (данные о полисе): http://netrika.ru/diagnostic-order-insurance-extension
10.5. DiagnosticOrder item.code.extension.coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/financial

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

Specimen

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

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

Ресурс Параметр Тип Кратность Описание
1. Specimen type CodeableConcept 0..1 Тип биоматериала (на момент написания документа справочник отсутствует)
1.1. Specimen type.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/biomaterial
1.2. Specimen type.Coding.code code 1..1 Код значения из справочника
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 В качестве кодовой системы указывается: http://netrika.ru/container-type-identifier
5.2. Specimen container.identifier.value code 1..1 Штрих-код
6. Specimen container.type CodeableConcept 0..1 Тип контейнера (На момент написания документа справочник отсутствует)
6.1. Specimen container.type.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/container-type
6.2. Specimen container.type.Coding.code code 1..1 Код значения из справочника

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

Encounter

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

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

Ресурс Параметр Тип Кратность Описание
1. Encounter identifier Identifier 1..1 Идентификатор случая обслуживания в МИС
1.1. Encounter identifier.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/mis-case-identifier
1.2. Encounter identifier.value code 1..1 Идентификатор случая обслуживания в МИС
2. Encounter status code 1..1 Статус ресурса (справочник FHIR)
3. Encounter class code 1..1 Тип Encounter (справочник FHIR)
4. Encounter type CodeableConcept 1..1 Тип случая обслуживания (региональный справочник типов случая обслуживания)
4.1. Encounter type.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/encounter-type
4.2. Encounter type.Coding.code code 1..1 Код значения из справочника
5. Encounter patient Patient 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
6. Encounter reason CodeableConcept 0..1 Цель посещения (региональный справочник целей посещения)
6.1. Encounter reason.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/reason-code
6.2. Encounter reason.Coding.code code 1..1 Код значения из справочника
7. Encounter indication Any 1..* Ссылка. Соотнесение с диагнозами пациента. Должен передаваться ресурс Condition в Bundle

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

Condition

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

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

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

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

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

Ресурс Параметр Тип Кратность Описание
1. Condition identifier Identifier 0..1 Для основного диагноза требуется указать код МЭС
1.1. Condition identifier.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/mes
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 Для диагноза указывается код согласно МКБ-10 Для признака менопаузы указывается True/False
4.1. Condition code.Coding.system uri 1..1 В качестве кодовой системы указывается:
  • http://netrika.ru/mkb10 для диагноза,
  • http://netrika.ru/menopause для признака менопаузы
4.2. Condition code.Coding.code code 1..1 Код значения из справочника
5. Condition category CodeableConcept 1..1 Указание типа Condition
5.1. Condition category.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/condition-category
5.2. Condition category.Coding.code code 1..1 Код значения из справочника
6. Condition status code 1..1 Статус ресурса (справочник FHIR)
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
1.1. Observation code.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/observation-name
1.2. Observation code.Coding.code code 1..1 Код значения из справочника
2. Observation status code 1..1 Статус ресурса (справочник FHIR)
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 В качестве кодовой системы указывается: http://netrika.ru/practitioner-identifier
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 Код должности врача (Номенклатура должностей медицинских работников и фармацевтических работников, OID 1.2.643.5.1.13.2.1.1.607)
4.1. Practitioner role.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/practitioner-role
4.2. Practitioner role.Coding.code code 1..1 Код значения из справочника
5. Practitioner specialty CodeableConcept 1..1 Код специальности врача (Номенклатура специальностей специалистов с высшим и послевузовским медицинским и фармацевтическим образованием в сфере здравоохранения, OID 1.2.643.5.1.13.2.1.1.181)
5.1. Practitioner specialty.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/practitioner-speciality
5.2. Practitioner specialty.Coding.code code 1..1 Код значения из справочника

Пример фрагмента 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 В качестве кодовой системы указывается: http://netrika.ru/lis-identifier
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)
6. OrderResponse description string 0..1 Комментарий к результату
7. OrderResponse fulfillment Any 1..* Ссылка. Соотнесение с результатом по услуге. Должен передаваться ресурс DiagnosticReport

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

DiagnosticReport

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

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

Ресурс Параметр Тип Кратность Описание
1. DiagnosticReport name CodeableConcept 1..1 Код услуги результата (Номенклатура медицинских услуг, 1.2.643.5.1.13.2.1.1.473)
1.1. DiagnosticReport name.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/diagnostic-order-code
1.2. DiagnosticReport name.Coding.code code 1..1 Код значения из справочника
2. DiagnosticReport status code 1..1 В сервисе предполагается получать только утвержденные результаты по услуге (справочник FHIR)
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 Бинарник с результатом и хэш

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

Observation

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

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

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

Ресурс Параметр Тип Кратность Описание
1. Observation code CodeableConcept 1..1 Код теста, для которого передается результат в Observation (региональный справочник тестов)
1.1. Observation code.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/observation-loinc
1.2. Observation code.Coding.code code 1..1 Код значения из справочника
2. Observation comments string 0..1 Комментарий к результату теста
3. Observation issued instant 1..1 Дата-время результата теста
4. Observation status code 1..1 Статус ресурса (справочник FHIR)
5. Observation method CodeableConcept 0..1 Методика исследования
5.1. Observation method.Coding.system uri 1..1 В качестве кодовой системы указывается: http://netrika.ru/observation-method
5.2. Observation method.Coding.code code 1..1 Методика
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 Причина, по которой результат отсутствует. В качестве кодовой системы указывается: http://netrika.ru/observation-data-absent-reason
9. Observation referenceRange low, high, meaning, age, text 1..1 усл Должен иметь хотя бы нижнее (элемент low), либо верхнее (элемент high) значение, либо элемент text Рефферентные значения для полученного результата

Пример фрагмента 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/fa946417-e236-4503-894b-5cfd5f22837a?_format=json

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

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

Более подробно о работе со справочниками можно посмотреть по адресу:

http://fhir-ru.github.io/valueset-operations.html

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

Перечень параметров для получения значений справочника приведен в [Таблица 21].

Таблица 21. Параметры запроса

Параметр Тип Кратность Описание
1. system string 1..1 Значение кодовой системы
Пример запроса

При запросе значений справочника в качестве адреса указывается URL в формате [base]/$expand?_format=json. В ответе сервис возвращает json с общей информацией о справочнике и массивом значений справочника в соответствии со значением кодовой системы.

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

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

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

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

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

Таблица 22. Параметры запроса

Параметр Тип Кратность Описание
1. system string 1..1 Значение кодовой системы
2. code string 1..1 Код значения в справочнике
Пример запроса

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

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

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

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

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

Перечень параметров для валидации кода значения в справочнике приведен в [Таблица 23].

Таблица 23. Параметры запроса

Параметр Тип Кратность Описание
1. system string 1..1 Значение кодовой системы
2. code string 1..1 Код значения в справочнике

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