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

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



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

Справочники, используемые в сервисе ДЛИ, опубликованы в «Сервисе Терминологии». Описание сервиса Терминологии и правила взаимодействия с ним приведены по ссылке: /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)
    13. Запрос ресурсов
    14. Отмена заявки ($cancelorder)
    15. Отмена результата ($cancelresult)
    16. Обоснованность назначений ($validity)
    17. Передача услуги (POST HealthcareService)
    18. Запрос списка услуг для заданной МО

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

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

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



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

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

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

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

    Таблица 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://b2b.n3health.ru/exlab/api/fhir/Patient/aba1a1c6-1476-4f80-bf3f-d75c0325bfe1
    authorization: N3[пробел][GUID передающей системы]
    content-type: application/json

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

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



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

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

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

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

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

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

    Таким образом, при передаче микроорганизма в ресурсе 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 приведена на рисунке ниже.

    Рисунок 8. Структура 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,
    • Данные о передаваемых ресурсах:
    • - Сам ресурс,
      - Операция над этим ресурсом.

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

    Рисунок 9. Структура 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

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

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

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

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

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

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

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

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

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

    № п/п Имя параметра Описание Кратность Тип
    1. OrderId GUID заявки в сервисе ДЛИ 1..1 string

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

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

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

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

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

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

    При отмене заявки сервис ОДЛИ помечает результат и все входящие в него ресурсы как отмененные. Такой результат более не может быть запрошена в сервисе методами запроса результата. Возможна повторная передача результата с таким же OrderMISID.

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

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

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

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

    № п/п Имя параметра Описание Кратность Тип
    1. OrderResponseId GUID заявки в сервисе ДЛИ 1..1 string

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

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

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

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

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

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

    Подготовка справочника

    Для работы метода в справочник «Код услуги заявки» должны быть добавлены три атрибута

    Таблица 30. Настройка ограничений в справочнике

    № п/п Наименование атрибута Описание Тип данных Пример заполнения
    1. Validity_Date Срок актуальности исследования в днях SimpleQuantity 14
    2. Validity_Practitioner Разрешенные коды должности врача String 24; 44; 56; 108
    3. Validity_Diagnosis Разрешенные коды диагноза пациента String I10; I11; K25; K26

    Ограничение метода: ЕСЛИ для услуги настраивается ограничение, ТО параметр Validity_Date ДОЛЖЕН быть заполнен обязательно.

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

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

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

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

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

    № п/п Имя параметра Описание Кратность Тип
    1. Code Код услуги, по которой запрашивается обоснованность 1..1 string
    2. Patient GUID пациента, для которого запрашивается обоснованность 1..1 string
    3. Diagnosis Код диагноза МКБ пациента, для которого запрашивается обоснованность 0..1 string
    4. Practitioner Код должности врача, запрашивающего исследование 0..1 string

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

    В случае, если указанный в запросе код услуги не найден в справочнике, или настройки ограничений не сделаны, сделаны неверно, отсутствуют для данной услуги - сервис вернет ошибку с HTTP кодом 422 и сообщением вида {"resourceType": "OperationOutcome","issue": [{"severity": "error","diagnostics": "%описание проблемы%"}]}

    Таблица 32. Интерпретация ответов метода

    № п/п Имя параметра Описание Результат == true Результат == false
    1. Code Валидация по наличию результатов в пределах срока актуальности В пределах срока актуальности такие исследования отсутствуют Есть результаты исследований в пределах срока актуальности
    2. Diagnosis Валидация по коду диагноза пациента Ограничений по диагнозу нет Исследование нельзя назначать при таком диагнозе
    3. Practitioner Валидация по коду должности врача Ограничений по должности врача нет Исследование нельзя назначать врачу на такой должности

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

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

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

    • Целевая МО, оказывающая перечень услуг, публикует этот перечень в сервисе путем передачи в сервис ресурсов HealthcareService (на каждую услугу передается один ресурс)
    • Целевая МО может дополнительно указать для каждой услуги перечень тестов, входящих в данную услугу. Коды тестов передаются в составе ресурса HealthcareService, описывающего конкретную услугу
    • Направляющая МО, использующая эти услуги в работе, запрашивает перечень доступных для целевой МО услуг и входящих в них тестов при помощи GET запроса ресурсов HealthcareService

    Списком услуг, доступных для целевой МО, может управлять только данная МО. Запрашивать список доступных услуг может любая МО.

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

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

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

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

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

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

    № п/п Параметр Тип Кратность Описание
    1. identifier identifier 1..* Идентификатор ресурса (код услуги, коды тестов)*
    • В параметре system указывается OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.31 для кода услуги, 1.2.643.2.69.1.1.1.1 или 1.2.643.5.1.13.13.11.1080 для кода теста
    • В параметре value указывается код услуги из справочника
    • В параметре Period указывается период действия услуги, в параметре Start дата начала действия услуги (не может быть пустым), в параметре End дата окончания действия услуги (может не передаваться)**
    2. providedBy Reference 1..1 Ссылка на организацию, предоставляющую данный набор услуг. В параметре display указывается OID передающей ИС

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

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

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

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

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

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

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

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

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

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

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

    GET [base]/ValueSet?_format=json&url=urn:oid:1.2.643.2.69.1.1.1.64

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

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

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

    GET [base]/ValueSet/1.2.643.2.69.1.1.1.64/$versions?_format=json

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

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

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

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

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

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

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

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

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

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

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

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

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

    ОДЛИ

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

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

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

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

    ОДИИ

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

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

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

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

    ОДР

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

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

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

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

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

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

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

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

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

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

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

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

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

    # Валидация Правило
    Общие правила валидации параметров
    V1Параметр обязательный. Кратность: {1..1, 1..2, 1..*}Параметр должен быть передан и не должен быть пустым
    V2Тип данных uri ИЛИ oidВалидация параметров с типом данных uri. Параметр должен передаваться по одной из схем:
    1. ИЛИ urn:oid:{значение}
    2. ИЛИ urn:uuid:{значение}

    a. Только для параметра Bundle.entry.fullUrl

    V3Параметр имеет тип Coding, CodeableConcept и содержит три вложенных параметра:
    1. system
    2. version
    3. code
    1. system — передаваемый OID справочника должен соответствовать ОИП
    2. version — версия должна быть актуальной
    3. code — значение должно существовать в справочнике с актуальной версией
    V4Параметр имеет тип Reference
    • ИЛИ должна быть ссылка на существующий в БД ресурс
    • ИЛИ должна быть ссылка на передаваемый ресурс в Bundle
    V5Кратность параметровЕсли параметр является массивом по FHIR И количество передаваемых элементов ограничено в ОИП, то должно выполняться следующее: Количество передаваемых элементов должно быть в диапазоне указанной кратности параметра согласно ОИП

    Кратность обозначается в ОИП: x..y, где x,y могут принимать значения 0,1, ..., * (Пример: 0..2, 1..2, ..)

    V6Параметр имеет тип DateTime или DateПараметр должен быть больше или равен текущей дате-времени / дате
    V7Параметр имеет тип Base64BinaryЗначение должно должно быть зашифровано по Base64
    V8Проверка изменений уникального ключа при обновлении (PUT) ресурсаПри обновлении ресурса методом PUT {имя ресурса}/{GUID ресурса} набор параметров, определяющий уникальность ресурса, должен совпадать у передаваемого ресурса в теле запроса и обновляемого {имя ресурса}/{GUID ресурса} в БД.
    Общие правила валидации Bundle
    V9Обязательность ресурсовВалидация обязательных ресурсов (кратность 1..*, 1..1, 1..2) согласно ОИП. Ресурс должен быть передан в составе Bundle
    V10Проверка ресурсов по признаку доступностиРесурсы, передаваемые в составе Bundle или передаваемые, как ссылка на существующий в БД ресурс: PractitionerRole, Practitioner, Device проверяются на признак доступности:
    • Practitioner.active == true
    • Device.status == active.
    Patient
    V11Уникальность Patient.identifier.systemPatient.identifier.system должен быть уникальным в пределах массива Patient.identifier
    V12Допустимые значения Patient.identifier.systemPatient.identifier.system должен содержать значения согласно ОИП
    V13Основной идентификатор пациентаВ теле запроса обязательно должен передаваться Patient.identifier с Patient.identifier.system = 1.2.643.5.1.13.2.7.100.5
    V14СМОЕсли передается идентификатор полиса ОМС старого/нового образца или временное свидетельство (system == 1.2.643.2.69.1.1.1.6.226 / 227 / 228), то:
    1. Patient.identifier.assigner.display должен содержать передаваться по правилу 1.2.643.5.1.13.2.1.1.635.[код страховой компании]
    2. код страховой компании должен быть в справочнике 1.2.643.5.1.13.2.1.1.635
    V15СНИЛСПри передаче СНИЛС (system == 1.2.643.2.69.1.1.1.6.223) должно выполняться следующее:
    1. Patient.identifier.assigner.display == ПФР
    2. Patient.identifier.value должен состоять только из числовых символов
    V16Проверка значения идентификатораPatient.identifier.value должен передаваться либо числом либо по маске "{символы}:{число}", кроме основного идентификатора пациента в ИС.
    Practitioner
    V17Уникальность Practitioner.identifier.systemPractitioner.identifier.system должен быть уникальным в пределах массива Practitioner.identifier
    V18Допустимые Practitioner.identifier.systemPractitioner.identifier.system должен содержать значения согласно ОИП
    V19Основной идентификатор врачаВ теле запроса обязательно должен передаваться Practitioner.identifier с Practitioner.identifier.system = 1.2.643.5.1.13.2.7.100.5
    V20СНИЛСПри передаче СНИЛС (system == 1.2.643.2.69.1.1.1.6.223) должно выполняться следующее:
    1. Practitioner.identifier.assigner.display == ПФР
    2. Practitioner.identifier.value должен состоять только из числовых символов
    Заявка
    V21Источник финансирования ОМСЕсли в заявке источник финансирования указан ОМС, то для пациента должен быть передан полис ОМС.
    V22Ссылки на пациентаВсе ссылки на пациента в бандле заявки должны совпадать со ссылкой на пациента в Order.subject
    V23Валидация ссылок на разрешенные ресурсыСервис ОДЛИ контролирует передаваемые типы ресурсов в параметрах типа reference. Параметр должен содержать ссылку только на указанный разрешенный ресурс
    V24Проверка передающей ИСПараметры:
    1. Encounter.identifier.system
    2. Patient.identifier.assigner.display при Patient.identifier.system = 1.2.643.5.1.13.2.7.100.5
    3. Practitioner.identifier.assigner.display при Practitioner.identifier.system = 1.2.643.5.1.13.2.7.100.5
    4. Device.identifier.system

    Должны совпадать с параметром Order.identifier.system

    Результат / результата без заявки
    V25Сравнение пациента с заявкой (только для результата)Все ссылки на пациента в бандле результата должны быть одинаковы и совпадать со ссылкой на пациента в заявке
    V26Валидация ссылок на разрешенные ресурсыСервис ОДЛИ контролирует передаваемые типы ресурсов в параметрах типа reference. Параметр должен содержать ссылку только на указанный разрешенный ресурс
    V27Проверка contentTypeBinary.contentType И DiagnosticReport.presentedForm.contentType должен равняться одному из принятых значений на проекте:
    • application/pdf
    • application/x-pkcs7-practitioner
    • application/x-pkcs7-organization
    V28Проверка передающей ИСПараметры:
    1. Practitioner.identifier.assigner.display при Practitioner.identifier.system = 1.2.643.5.1.13.2.7.100.5
    2. Device.identifier.system

    Должны совпадать с параметром Order.identifier.system

    V29Проверка передающей ИС (только для результата без заявки)Параметр Patient.identifier.assigner.display при Patient.identifier.system = 1.2.643.5.1.13.2.7.100.5 должен совпадать с параметром Order.identifier.system
    V30Соответствие contentTypeПараметры Binary.contentType И DiagnosticReport.presentedForm.contentType должны совпадать для одного и того же переданного ресурса Binary
    V31Проверка УКЭПВ проверке участвуют ресурсы: Binary, DiagnosticReport, PractitionerRole, Practitioner

    Если в ресурсе DiagnosticReport передаются три ссылки на ресурсы Binary со следующими contentType:

    • DiagnosticReport.presentedForm.contentType == application/pdf
    • DiagnosticReport.presentedForm.contentType == application/x-pkcs7-practitioner
    • DiagnosticReport.presentedForm.contentType == application/x-pkcs7-organization
    1. Проверка на обязательность СНИЛС врача. Ресурс Practitioner должен содержать СНИЛС. Practitioner.identifier.value обязательный при Practitioner.identifier.system == urn:oid:1.2.643.2.69.1.1.1.6.223
    2. Проверка СНИЛС врача на соответствие СНИЛС в УКЭП врача Practitioner.identifier.value при Practitioner.identifier.system == urn:oid:1.2.643.2.69.1.1.1.6.223 должен совпадать со СНИЛС, указанным в подписи врача (Binary.data с Binary.contentType == application/x-pkcs7-practitioner).
    3. Проверка ФИО (ресурс Practitioner) на соответствие УКЭП (Binary.data с Binary.contentType == application/x-pkcs7-practitioner). Должно выполняться следующее:
      • Practitioner.name.family == полю SN подписи
      • Practitioner.name.given[0] == полю G[0] подписи
      • Practitioner.name.given[1] == полю G[1] подписи.

      Если G[1] отсутствует в подписи, то соответствие не проверяется. Сравнение регистронезависимое.

    4. Проверка ОГРН. ОГРН МО в подписи должен совпадать с ОГРН МО, передаваемом в Bundle
      • ОГРН МО подписи == параметр ОГРН подписи Binary.data с Binary.contentType == application/x-pkcs7-organization
      • ОГРН МО в Bundle == параметр Organization.ogrn. Ресурс Organization взять по ссылке Orderresponse.who передаваемого результата
    5. Проверка даты результата на действие УКЭП. Параметр DiagnosticReport.issued должен входить в период действия УКЭП (вычислить из документа Binary с Binary.contentType == application/x-pkcs7-practitioner).
    Ссылки на ресурсы

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

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

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

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

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

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

    Тип ссылки Описание Пример
    1На внутренний ресурс передаваемый в составе BundleПередается значение параметра fullUrl ссылаемого ресурса"subject": { "reference":"urn:uuid:f0ceca14-6847-4ea4-b128-7c86820da555" }
    2На созданный ранее ресурсПередается по схеме [resourceType]/[GUID]"subject": { "reference":"Patient/a0a7a0e8-c445-455b-8b2d-6618b26f8371" }
    Использование fullUrl

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ресурс Параметр Тип Кратность Описание
    1Patientidentifier.systemuri1..1Пространство имён идентификатора. OID (1.2.643.5.1.13.2.7.100.9)
    2Patientidentifier.usecode0..1Способ прикрепления (справочник FHIR):
    • usual – по территориальноучастковому принципу
    • official – по заявлению
    • temp – на период первоначального прикрепления без заявления
    3Patientidentifier.typeCodeableConcept0..1Код участка прикрепления
    • В параметре system указывается OID справочника участков в сервисе Терминологии
    • В параметре version указывается версия справочника в сервисе Терминологии
    • В параметре code указывается код значения из справочника
    4Patientidentifier.valuestring1..1Значение профиля прикрепления по справочнику 1.2.643.2.69.1.1.1.56.

    Допустимые значения:

    • 113 (терапия)
    • 49 (педиатрия)
    • 126 (ВОП)
    • 69 (стоматология)
    • 21 (акушерство и гинекология)
    • 0 (прикрепление по всем профилям)
    5Patientidentifier.periodPeriod0..1Период прикрепления. Может быть указана одна или обе даты.
    • В параметре start указывается дата начала периода.
    • В параметре end – дата окончания периода.
    6Patientidentifier.assigner.referenceReference0..1 услСсылка. Соотнесение с организацией прикрепления.
    7Patientidentifier.assigner.displaydisplay0..1 услТекстовое наименование участка прикрепления.

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

    {
     "system": "urn:oid:1.2.643.5.1.13.2.7.100.9",
     "use": "temp",
     "type": {
       "coding": [
         {
          "system": "urn:oid:{XXXXXXXXXXXXXXX}",
          "version": "1",
          "code": "1"
         }
       ]
      },
     "value": "0",
     "period": {
       "start": "2010-05-05",
       "end": "2018-05-05",
     },
     "assigner": {
         "reference": "Organization/a762831e-dd4c-46be-a329-6dd592a14bb6"
      }
    }
    
    Бизнес-логика
    Передача пациента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Бизнес-логика
    Передача врача

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Код Наименование Сокращенное наименование
    448Колониеобразующая единицаКОЕ
    449Миллион колониеобразующих единицмлн. КОЕ
    450Миллиард колониеобразующих единицмлрд. КОЕ
    451Колониеобразующая единица в граммеКОЕ/г
    452Миллион колониеобразующих единиц в граммемлн.КОЕ/г
    500Колониеобразующая единица на дозуКОЕ/доз
    501Миллион колониеобразующих единиц на дозумлн. КОЕ/доз
    502Миллиард колониеобразующих единиц на дозумлрд. КОЕ/доз

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

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

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

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

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

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

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

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

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

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

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

    Условия:

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

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

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

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

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

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

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

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

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

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

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

    Identifier.typeCodeableConceptТип идентификатора.
    • В параметре system указывается OID справочника типов идентификаторов FHIR (1.2.643.2.69.1.1.1.122).
    • В параметре version указывается версия справочника в сервисе Терминологии,
    • В параметре code – код типа идентификатора. Для эпидномера всегда передается RRI.
    identifier.systemuriПространство имён идентификатора. Для эпидномера всегда передается OID (1.2.643.5.1.13.2.7.100.6)
    identifier.valuestringЭпидномер. В идентификаторах запрещены пробелы и спецсимволы (прямой и обратный слэш, кавычки, %, $ и др.)
    identifier.assigner.referenceReference (Organization)Ссылка. Соотнесение с организацией, присвоившей эпидномер
    identifier.assigner.displaystringВсегда указывается «Эпидномер»

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

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

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

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

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

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

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

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

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

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

    Статус заявки Описание ситуации
    1Not foundЗаявки нет в сервисе
    2RequestedЗаявка отправлена из МИС в сервис и не запрашивалась из ЛИС
    3ReceivedЗаявку запросили из ЛИС
    4AcceptedНа заявку дан частичный ответ, должно быть продолжение
    5CompletedНа заявку дан полный ответ, работа по заявке в ЛИС завершена
    6CancelledЗаявка отменена

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

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

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

    Статус заявки Описание ситуации Наиболее вероятная причина
    1Not foundЗаявки от МИС нет в сервисеМИС не передавала заявку или при передаче возникли ошибки
    2RequestedЗаявка отправлена из МИС в сервис и не запрашивалась из ЛИСЛИС не запрашивала заявку или при запросе возникли ошибки
    3ReceivedЗаявка передана МИС в сервис и запрашивалась из ЛИС, но ответа на заявку пока нетЛИС не выполнила исследование и не передавала результат, или при передаче результата возникли ошибки
    4AcceptedЗаявка частично выполнена в ЛИСЛИС выполнила заявку частично. Если результата нет в МИС – МИС не запрашивала результат или при запросе результата возникли ошибки
    5CompletedЗаявка полностью выполнена в ЛИСЛИС выполнила заявку полностью. Если результата нет в МИС – МИС не запрашивала результат или при запросе результата возникли ошибки
    6CancelledЗаявка отменена из МИС
    Получение детальной информации по заявке

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

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

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

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

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

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

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

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

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

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

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

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

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

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