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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

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

Рисунок 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 передающей системы должен соответствовать идентификатору информационной системы, указанному в идентификаторе заявки или результата.



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

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

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

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

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

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

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


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

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

    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)

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



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

    Для регистрации пациента в сервисе ДЛИ используется POST-запрос ресурса Patient. Данные ДУЛ, полиса и СНИЛС пациента передаются в параметре identifier.
    При передаче данных анонимных пациентов следует в ресурсе Patient передавать параметр name.use = “anonimous”.
    Уникальность пациента проверяется по совокупности параметров ID МИС и ИД пациента в МИС. Многократная передача одного и того же пациента из одной и той же МИС с разными идентификаторами МИС не допускается.

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

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

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

    Параметр Тип Кратность Описание
    1. id identifier 1..1 усл Должен передаваться при обновлении методом PUT GUID ресурса Patient для обновления методом PUT
    2 identifier Identifier 1..* Должен передаваться хотя бы идентификатор в ИС (identifier.system 1.2.643.5.1.13.2.7.100.5) Идентификатор пациента. Указывает код пациента в МИС, ЛИС, ДУЛ, полисы, СНИЛС, информацию по прикреплению
    2.1identifier.system uri 1..1 Пространство имён идентификатора. Указывается код:
  • для идентификатора в МИС/ЛИС OID (1.2.643.5.1.13.2.7.100.5)
  • для идентификатора прикрепления OID (1.2.643.5.1.13.2.7.100.9)
  • для ДУЛ и полисов OID (1.2.643.2.69.1.1.1.6.Х), где Х = код документа в справочнике 1.2.643.2.69.1.1.1.6. Для ДУЛ допустимые значения (1-18), для полисов ОМС (226-228), для полисов ДМС 240.
  • 2.2 identifier.value string 1..1 Значение для идентификатора или для документа.
  • для идентификатора в МИС/ЛИС указывается [идентификатор в МИС/ЛИС]
  • для ДУЛ и полисов указывается [Серия]:[Номер] или [Номер], если нет серии, номер - обязателен. В серии не должны использоваться разделители (пробелы, тире и т.д.), допускаются цифры и буквы русского и латинского алфавита. В номере не должны использоваться разделители (пробелы, тире и т.д.), допускаются только цифры.
  • 2.3 identifier.period Period 0..1 Период действия для паспорта и полиса.
  • В параметре start указывается дата начала периода.
  • В параметре end – дата окончания периода.
  • 2.4 identifier.assigner.display string 1..1
  • Указывается OID передающей ИС для идентификатора пациента.
  • Для ДУЛ – наименование выдавшей организации
  • Для полиса ОМС любого типа указывается 1.2.643.5.1.13.2.1.1.635.[код страховой компании]
  • Для полиса ДМС – наименование СМО ДМС
  • Для СНИЛС – «ПФР»
  • 3 managingOrganization Reference(Organization) 1..1 Ссылка. Соотнесение с организацией, присвоившей идентификатор
    4 name 1..1 HumanNameИнформация о ФИО пациента
    4.1 name.family string 1..2 Фамилия, Отчество. Сначала указывается фамилия.
    4.2 name.given string 1..1 Имя
    4.3 name.use code 0..1 Код типа имени (справочник FHIR). Передается только значение “anonymous” при передаче данных по анонимному пациенту
    5 gender code 1..1 Код пола пациента (справочник FHIR. OID: 1.2.643.2.69.1.1.1.40)
    6 birthDate date 1..1 Дата рождения (yyyy-MM-dd)
    7 address Address 0..* Информация об адресе пациента
    7.1 address.use code 1..1 Тип адреса (справочник FHIR. OID: 1.2.643.2.69.1.1.1.41)
  • home - Адрес проживания
  • temp - Адрес регистрации
  • 7.2 address.text string 1..1 Адрес строкой
    7.3 address.line string 0..1 Улица, номер дома, номер квартиры
    7.4 address.state string 0..1 Регион
    7.5 address.city string 0..1 Город
    7.6 address.district string 0..1 Район
    7.7 address.postalCode string 0..1 Почтовый индекс

    Помимо перечисленных выше параметров, в сервис может быть передан дополнительный идентификатор прикрепления (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
  • Таблица 2. Параметры идентификатора прикрепления

    № п/п Параметр Тип Кратность Описание
    1.1 identifier.system uri 1..1 Пространство имён идентификатора. OID (1.2.643.5.1.13.2.7.100.9)
    1.2 identifier.use code 0..1 Способ прикрепления (справочник FHIR)
  • usual – по территориально-участковому принципу
  • official – по заявлению
  • temp – на период первоначального прикрепления без заявления
  • 1.3 identifier.value string 1..1 Значение профиля прикрепления по справочнику 1.2.643.2.69.1.1.1.56. Допустимые значения:
  • 113 (терапия)
  • 49 (педиатрия)
  • 126 (ВОП)
  • 69 (стоматология)
  • 21 (акушерство и гинекология)
  • 0 (прикрепление по всем профилям)
  • 1.4 identifier.period Period 0..1 Период прикрепления. Может быть указана одна или обе даты.
  • В параметре start указывается дата начала периода.
  • В параметре end – дата окончания периода.
  • 1.5 identifier.assigner.reference Reference 0..1 усл Ссылка. Соотнесение с организацией прикрепления. Не передается при откреплении пациента от МО
    1.6 identifier.assigner.display display 0..1 усл Текстовое наименование участка прикрепления. Не передается при откреплении пациента от МО
    Пример запроса

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

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



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

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

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

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

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

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

    GET
    http://r78-rc.zdrav.netrika.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.

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

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

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

    № п/п Параметр Тип Кратность Описание
    1 id Identifier 1..1 усл Должен передаваться при обновлении методом PUT GUID ресурса Practitioner для обновления методом PUT
    2 identifier Identifier 1..2 Должен передаваться хотя бы идентификатор в ИС (identifier.system 1.2.643.5.1.13.2.7.100.5) Идентификатор врача (идентификатор в МИС/ЛИС или СНИЛС)
    2.1 identifier.system uri 1..1 Пространство имён идентификатора. Указывается код:
  • OID для идентификатора в МИС/ЛИС (1.2.643.5.1.13.2.7.100.5)
  • OID ПФР для СНИЛСа (1.2.643.2.69.1.1.1.6.223)
  • 2.2 identifier.value string 1..1 Значение для идентификатора или для СНИЛСа
    2.3 identifier. assigner.display string 1..1
  • Указывается OID передающей ИС для идентификатора пациента
  • Для СНИЛС – «ПФР»
  • 3 name HumanName 1..1 ФИО врача
    3.1 name.family string 1..2 Фамилия, Отчество. Сначала указывается Фамилия
    3.2 name.given string 1..1 Имя
    4 practitionerRole BackboneElement 1..1 Сведения о враче
    4.1 practitionerRole.managingOrganization Reference(Organization) 1..1 Ссылка. Соотнесение с организацией, в которой работает врач. Должна указываться ссылка на существующую в БД Organization
    4.2 practitionerRole.role CodeableConcept 1..1 Код должности врача (Номенклатура должностей медицинских работников и фармацевтических работников)
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1002)
  • В параметре version указывается версия справочника в сервисе Терминологии
  • В параметре code указывается код значения из справочника
  • 4.2 practitionerRole.specialty CodeableConcept 1..1 Код специальности врача (Номенклатура специальностей специалистов с высшим и послевузовским медицинским и фармацевтическим образованием в сфере здравоохранения):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1066)
  • В параметре version указывается версия справочника в сервисе Терминологии
  • В параметре code указывается код значения из справочника
  • Пример запроса приведен в разделе "Примеры запросов".



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

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

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

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

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

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



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

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

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


    Структура Bundle

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

    Order

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

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

    № п/п Параметр Тип Кратность Описание
    1. identifier Identifier 1..1 Идентификатор заявки в МИС
    1.1 identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы
    1.2 identifier.value string 1..1 Идентификатор заявки в МИС
    1.3 identifier.assigner Reference (Organization) 1..1 Ссылка. Соотнесение с кодом МО (или отделения). Должна указываться ссылка на существующую в БД Organization
    2. date dateTime 1..1 Дата заявки (yyyy-MM-ddTHH:mm:sszzz)
    3. subject Reference (Patient) 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
    4. source Reference (Practitioner) 1..1 Ссылка. Соотнесение с автором заявки. Должен передаваться ресурс Practitioner в Bundle или указывается ссылка на существующий Practitioner
    5. target Reference (Organization) 1..1 Ссылка. Соотнесение с целевой лабораторией. Должна указываться ссылка на существующую в БД Organization
    6. when BackboneElement 1..1 Сведения о приоритете выполнения
    6.1 when.code CodeableConcept 1..1 Приоритет выполнения (отметка срочности):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.30),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
  • 7. detail Reference (DiagnosticOrder) 1..* Ссылка. Соотнесение с клинической частью (DiagnosticOrder). Должен передаваться ресурс DiagnosticOrder в Bundle

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


    DiagnosticOrder

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

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

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


    Specimen

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

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

    № п/п Параметр Тип Кратность Описание
    1. container BackboneElement 0..1 Сведения о контейнере с биоматериалом
    1.1 container.identifier Identifier 0..1 Штрих-код контейнера с биоматериалом
    1.1.1 container.identifier.system uri 1..1 В качестве кодовой системы указывается код лаборатории
    1.1.2 container.identifier.value string 1..1 Штрих-код. Должен быть уникален на протяжении как минимум срока жизни образца, рекомендуется – на протяжении как минимум трех месяцев.
    1.2 container.type CodeableConcept 0..1 Тип контейнера:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.34)
  • В параметре version указывается версия справочника в сервисе Терминологии
  • В параметре code указывается код значения из справочника
  • 2. type CodeableConcept 0..1 Тип биоматериала:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1081)
  • В параметре version указывается версия справочника в сервисе Терминологии
  • В параметре code указывается код значения из справочника
  • 3. subject Reference (Patient) 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
    4. collection BackboneElement 1..1 Сведения о биоматериале
    4.1. collection.comment string 0..1 Комментарий к биоматериалу
    4.2 collection.collectedDateTime dateTime 1..1 Дата-время сбора биоматериала (yyyy-MM-ddTHH:mm:sszzz)

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

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


    Encounter

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

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

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

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

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


    Condition

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

    • Для диагноза category = diagnosis.
    • Для признака менопаузы category = finding.

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

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

    № п/п Параметр Тип Кратность Описание
    1. patient Reference (Patient) 1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
    2. category CodeableConcept 1..1 Указание типа ресурса (диагноз или признака менопаузы):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.36)
  • В параметре version указывается версия справочника в сервисе Терминологии
  • В параметре code указывается код значения из справочника
  • 3. dateRecorded date 1..1 Дата установления (диагноза или признака менопаузы)
    4. 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. verificationStatus code 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.62)
    6. notes string 0..1 усл. Диагноз. Клиническая (текстовая) формулировка. Обязательна при передаче кода диагноза

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


    Observation

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

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

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

    № п/п Параметр Тип Кратность Описание
    1. code CodeableConcept 1..1 Указание типа Observation:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.37)
  • В параметре version указывается версия справочника в сервисе Терминологии
  • В параметре code указывается код значения из справочника
  • 2. status code 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.47). Всегда передается статус final
    3. valueQuantity Quantity 1..1 Значение Observation
  • В параметре value указывается количественный показатель
  • Пример фрагмента 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 приведены в таблице ниже.

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

    № п/п Имя параметра Описание Кратность Тип Использование
    1. SourceCode Код направившей организации (АПУ, стационара). Указывается код из регионального справочника МО 0..1 string in
    2. TargetCode Код целевой организации (КДЛ) 0..1 string in
    3. Barcode Штрих-код контейнера с биоматериалом string in
    4. OrderMisID Идентификатор заявки в МИС 0..1 (обязателен Barcode или OrderMisID) string in
    StartDate Диапазон поиска (начало). Если время не указано, поиск идет с 00:00:00 0..1 dateTime (yyyy-MM-ddTHH:mm:sszzz) in
    EndDate Диапазон поиска (конец). Если время не указано, поиск идет по 23:59:59 0..1 dateTime (yyyy-MM-ddTHH:mm:sszzz) in
    7. Order Заявка 0..* Order out
    Пример запроса

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

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



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

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

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

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

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

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

    № п/п Имя параметра Описание Кратность Тип Использование
    1. SourceCode Код направившей организации (МО). 0..1 string in
    2. TargetCode Код лаборатории, которая должна выполнить исследование (КДЛ, МЦКДЛ). Указывается код из регионального справочника МО 1..1 string in
    3. StartDate Дата начала диапазона поиска по дате заявки 1..1 dateTime (yyyy-MM-ddTHH:mm:sszzz) in
    4. EndDate Дата окончания диапазона поиска по дате заявки 0..1 dateTime (yyyy-MM-ddTHH:mm:sszzz) in
    5. Order Заявка 0..* Order out
    Пример запроса

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

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



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

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

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


    Структура Bundle

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

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

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

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

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


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

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

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

    № п/п Ресурс Кратность Операции Возможность использования ссылки на ресурс
    1. OrderResponse 1..1 Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий
    2. DiagnosticReport 0..* усл. Создание (POST)

    Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий. Исключение: может не передаваться, если статус заявки OrderResponse.orderstatus = rejected или error

    3. Observation 0..* усл. Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий. Исключение: может не передаваться, если статус заявки OrderResponse.orderstatus = rejected или error
    4. Binary 0..* усл. Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий. Исключение: может не передаваться, если статус заявки OrderResponse.orderstatus = rejected или error
    5. Practitioner 0..*
  • Создание (POST)
  • Обновление (PUT)
  • Ресурс может не передаваться, указывается ссылка на уже существующий
    6. Device 0..*
  • Создание (POST)
  • Обновление (PUT)
  • Ресурс может не передаваться, указывается ссылка на уже существующий

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


    DiagnosticReport

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

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

    Параметр Тип Кратность Описание
    1. meta.security.code code 1..1 Метаданные ресурса с данными об уровне доступа к результату исследования. В параметре code указывается код уровня доступа из справочника (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.5.1.13.13.11.1116 N – обычный, R - ограниченный, V - крайне ограниченный )
    2. code CodeableConcept 1..1 Код услуги результата (Номенклатура медицинских услуг):
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.31),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
  • 3. status code 1..1 В сервисе предполагается получать только утвержденные результаты по услуге (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.46)
    4. category CodeableConcept 0..1 Вид лабораторного исследования:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1117),
  • В параметре version указывается версия справочника в сервисе Терминологии,В параметре code указывается код значения из справочника
  • 5. effectiveDateTime dateTime 1..1 Клинически значимое время результата: обычно дата-время сбора биоматериала (Specimen.collection.collectedDateTime), если неизвестно (результат без заявки) - дата-время утверждения результата по услуге (DiagnosticReport.issued)
    6. issued instant 1..1 Дата-время утверждения результата по услуге
    7. subject Reference (Patient) 1..1 Ссылка. Соотнесение с пациентом. Должна указываться ссылка на существующий в БД Patient. При передаче результата по заявке ссылка на пациента в результате и ссылка на пациента в заявке должны быть одинаковые
    8. specimen Reference (Specimen) 0..1 усл. Ссылка. Соотнесение с биоматериалом. Должна указываться ссылка на ресурс Specimen в Bundle (только для bundle результат без заявки)
    9. performer Reference (Practitioner) 1..1 Ссылка. Соотнесение с врачом, утвердившим результат. Должен передаваться ресурс Practitioner в Bundle или указывается ссылка на существующий Practitioner
    10. request Reference (DiagnosticOrder) 1..1 усл. Ссылка. Соотнесение с назначением (DiagnosticOrder). Должна указываться ссылка на существующий в БД DiagnosticOrder. Не передается в результате без заявки
    11. result Reference (Observation) 1..* Ссылка. Соотнесение с результатом теста. Должен передаваться ресурс Observation
    12. conclusion string 1..1 Текст заключения по услуге
    13. presentedForm Attachment 1..1 Электронная версия документа с результатом по услуге
    13.1 presentedForm.url uri 1..1 Ссылка на ресурс Binary. Соотнесение с PDF-документом.
    14. codedDiagnosis CodeableConcept 0..* Заключение: диагноз пациента:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.2),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения согласно МКБ-10
  • Пример фрагмента Bundle для DiagnosticReport приведен в разделе "Примеры запросов".

    Observation

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

    Таблица 18. Виды Observation

    OID справочника Назначение Обязательность заполнения полей valueQuantity, valueString
    1.2.643.2.69.1.1.1.1 или 1.2.643.5.1.13.13.11.1080 Для передачи результата теста клинического исследования Должно передаваться или valueQuantity, или valueString, или dataAbsentReason
    1.2.643.5.1.13.13.11.1087 Для передачи информации о выявленном микроорганизме (бактерии) Может передаваться
    1.2.643.5.1.13.13.11.1088 Для передачи информации о выявленном микроорганизме (грибы) Может передаваться
    1.2.643.2.69.1.1.1.74 Для передачи информации об антибиотике, чувствительность к которому определялась Не должно передаваться
    1.2.643.2.69.1.1.1.94 Для передачи информации о том, что микрофлора не выявлена Не должно передаваться

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

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

    № п/п Параметр Тип Кратность Описание
    1. code CodeableConcept 1..1 Код теста, для которого передается результат в Observation:
  • В параметре system указывается OID справочника в сервисе Терминологии (см. таблицу выше),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
  • 2. comments string 0..1 Комментарий к результату теста
    3. interpretation CodeableConcept 1..1 Интерпретация результата теста: норма или выход за границы норм для клинических исследований, для микробиологических рост или отсутствие роста, чувствительность к антибиотикам:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1381),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
  • 4. issued instant 1..1 Дата-время выполнения теста
    5. status code 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 1.2.643.2.69.1.1.1.47). Всегда передается статус final.
    6. method CodeableConcept 0..1 Методика исследования:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.76)
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
  • 7. performer Reference (Practitioner) 1..1 Ссылка. Соотнесение с врачом-исполнителем. Должен передаваться ресурс Practitioner в Bundle или указываться ссылка на существующий Practitioner
    8. valueQuantity Quantity 1..1 усл Числовой результат теста с единицами измерения. Условия обязательности приведены в таблице выше
    8.1. valueQuantity.value decimal 1..1 Числовой результат теста
    8.2. valueQuantity.code code 1..1 Код единицы измерения по справочнику 1.2.643.5.1.13.13.11.1358
    8.3. valueQuantity.comparator code 0..1 Интерпретация и сравнение полученного значения. Используемые знаки для сравнения (< | <= | >= | >) (только для результата микробиологического исследования
    9. valueString string 1..1 усл Текстовый результат теста. Условия обязательности приведены в таблице выше
    10. dataAbsentReason CodeableConcept 1..1 усл Причина, по которой результат отсутствует. Условия обязательности приведены в таблице выше.
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.38),
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
  • 11. referenceRange BackboneElement 1..1 усл Референтные значения для полученного результата. Должен иметь хотя бы нижнее (элемент low) либо верхнее (элемент high) значение, либо элемент text
    11.1. referenceRange.low SimpleQuantity 1..1 усл Нижняя граница порогового значения нормы:
  • В параметре value указывается количественный показатель,
  • В параметре code – код единицы измерения по справочнику 1.2.643.5.1.13.13.11.1358
  • 11.2. referenceRange.high SimpleQuantity 1..1 усл Верхняя граница порогового значения нормы.
  • В параметре value указывается количественный показатель,
  • В параметре code – код единицы измерения по справочнику 1.2.643.5.1.13.13.11.1358
  • 11.3. referenceRange.text string 1..1 усл Текстовое значения для указания референтного значения
    12. device Reference (Device) 0..1 Ссылка. Соотнесение с прибором исследования (Device). Должен передаваться ресурс Device в Bundle или указываться ссылка на существующий ресурс
    13. related BackboneElement 0..* Информация об антибиотиках в микробиологическом исследовании.
    13.1. related.target Observation 1..1 Ссылка на ресурс Observation, в котором передается антибиотик. Всегда передается ресурс.

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

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


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

    Микробиологическое исследование состоит из следующих информационных объектов:

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

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

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

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

    Таким образом, при передаче микроорганизма в ресурсе 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 предназначен для передачи информации об устройстве, которое использовалось для получения результата исследования.

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

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

    № п/п Параметр Тип Кратность Описание
    1. type CodeableConcept 1..1 Тип устройства:
  • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1071)
  • В параметре version указывается версия справочника в сервисе Терминологии,
  • В параметре code указывается код значения из справочника
  • 2. manufacturer string 0..1 Название производителя устройства
    3. model string 0..1 Идентификатор модели устройства, присвоенный производителем
    4. version string 0..1 Номер версии устройства
    5. manufactureDate dateTime 0..1 Дата производства устройства
    6. expiry dateTime 0..1 Дата истечения срока эксплуатации устройства
    7. udi string 0..1 Штрих-кода уникального идентификатора устройства
    8. owner Reference (Organization) 1..1 Ссылка. Соотнесение с организацией, которая ответственная за устройство

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




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

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

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

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

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

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

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

    № п/п Ресурс Ссылки на другие ресурсы Описание
    1.Order
  • Order.source – ссылка на Organization,
  • Order.target – ссылка на Organization
  • В ресурсе указывается информация о направляющей МО и лаборатории:
  • ссылка на направляющую МО (или отделение),
  • ссылка на целевую лабораторию
  • 2. OrderResponse См. описание ресурсов, входящих в состав Bundle результата См. описание ресурсов, входящих в состав Bundle результата
    3. DiagnosticReport См. описание ресурсов, входящих в состав Bundle результата. Дополнительно: DiagnosticReport.specimen – ссылка на Specimen См. описание ресурсов, входящих в состав Bundle результата
    4. Observation См. описание ресурсов, входящих в состав Bundle результата См. описание ресурсов, входящих в состав Bundle результата
    5. Specimen См. описание ресурсов, входящих в состав Bundle результата См. описание ресурсов, входящих в состав Bundle результата
    6. Practitioner См. описание ресурсов, входящих в состав Bundle результата См. описание ресурсов, входящих в состав Bundle результата
    7. Patient См. описание ресурсов, входящих в состав Bundle результата См. описание ресурсов, входящих в состав Bundle результата
    8. Device См. описание ресурсов, входящих в состав Bundle результата См. описание ресурсов, входящих в состав Bundle результата
    9. Binary См. описание ресурсов, входящих в состав Bundle результата См. описание ресурсов, входящих в состав Bundle результата

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

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

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

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

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

    № п/п Ресурс Кратность Операции Возможность использования ссылки на ресурс
    1. Order 1..1 Создание (POST) Всегда должен передаваться ресурс
    2. OrderResponse 1..1 Создание (POST) Всегда должен передаваться ресурс
    3. DiagnosticReport 0..* усл. Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий. Исключение: может не передаваться, если статус заявки OrderResponse.orderstatus = rejected или error
    4. Observation 0..* усл. Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий. Исключение: может не передаваться, если статус заявки OrderResponse.orderstatus = rejected или error
    5. Binary 0..* усл. Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий. Исключение: может не передаваться, если статус заявки OrderResponse.orderstatus = rejected или error
    6. Specimen 0..* Создание (POST) Должен передаваться ресурс. Может не передаваться, если нет необходимой информации
    7. Practitioner 0..* Создание (POST) Ресурс может не передаваться, указывается ссылка на уже существующий
    8. Patient 0..1 Создание (POST) Ресурс может не передаваться, указывается ссылка на уже существующий
    9. Device 0..* Создание (POST) Ресурс может не передаваться, указывается ссылка на уже существующий

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

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

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

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

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

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

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


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

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

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

    № п/п Параметр Тип Кратность Описание
    1. source Reference (Organization) 1..1 Ссылка. Соотнесение с кодом МО (или отделения). Должна указываться ссылка на существующую в БД Organization
    2. target Reference (Organization) 1..1 Ссылка. Соотнесение с целевой лабораторией. Должна указываться ссылка на существующую в БД Organization
    3. detail Reference (Any) 1..1 Пустая ссылка

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



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

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

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

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

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

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

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

    № п/п Имя параметра Описание Кратность Тип Использование
    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 приведены в таблице ниже.

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

    № п/п Имя параметра Описание Кратность Тип Использование
    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 приведены в таблице ниже.

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

    № п/п Имя параметра Описание Кратность Тип Использование
    1. SourceCode Код направившей организации (МО) 1..1 string in
    2. TargetCode Код целевой организации (КДЛ) 0..1 string in
    3. StartDate Диапазон поиска (начало). Если время не указано, поиск идет с 00:00:00 1..1 dateTime (yyyy-MM-ddTHH:mm:sszzz) in
    4. EndDate Диапазон поиска (конец). Если время не указано, поиск идет по 23:59:59 0..1 dateTime (yyyy-MM-ddTHH:mm:sszzz) in
    5. OrderResponse Результат 0..* OrderResponse out
    Пример запроса

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

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

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

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

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