ОДИИ

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

Настоящее описание интеграционных профилей сервиса «Обмена данными  инструментальных исследований» определяет механизмы информационного взаимодействия медицинских информационных систем (далее – МИС), систем инструментальной диагностики (РИС), сервисов хранения изображений (PACS) и сервиса «Обмен данными инструментальных исследований» (далее – сервис ОДИИ), входящих в состав Регионального сегмента Единой государственной системы в сфере здравоохранения.

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

В рамках информационного взаимодействия сервис ОДИИ поддерживает получение следующих сведений от сторонних информационных систем:

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

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

Описание решения

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

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

Сервис обеспечивает:

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

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

    1. Добавление заявки. При добавлении заявки в подсистему ОДИИ передается информация о пациенте, которому назначено исследование и заявка. При этом пациент:
        а) Может использоваться ссылка на уже существующего пациента без изменений. 
        b) Может быть обновлен при необходимости, если был зарегистрирован ранее
        c) Должен добавляться, если не был зарегистрирован в нем ранее,

2. Запрос заявки. Заявка не передается в РИС автоматически. РИС диагностического
отделения запрашивает заявку у подсистемы ОДИИ.

3. Добавление расписания устройства. РИС диагностического отделения после получения заявки передает в сервис ОДИИ данные об устройстве, на котором планируется выполнение исследование, и расписание.

4. Добавление результата. В подсистему ОДИИ должны передаваться только утвержденныерезультаты исследований.

5. Запрос статуса заявки. Информация об изменении статуса заявки не передается в МИС автоматически. МИС МО запрашивает статус заявки у подсистемы ОДИИ.

6. Запрос результата. Результат не передается в МИС автоматически. МИС МО запрашивает результат у подсистемы ОДИИ.

7. Обмен данными о пациенте. При информационном взаимодействии могут осуществляться следующие операции:
а) Добавление пациента. Осуществляется передача данных о пациенте, которому необходимо осуществить исследование
b) Обновление данных. Возможны два варианта:
i. Обновление базовой информации о пациенте (ФИО, адрес, паспорт)
ii. Обновление информации о страховых полисах (ОМС).
Обновление ресурса разрешено только создателям данного ресурса.
c) Получение данных о пациенте по запросу. МИС МО или РИС диагностического отделения может запрашивать актуальную информацию о пациенте и его полисах.
8. Обмен данными об устройствах (диагностических аппаратов).
a. Добавление устройства. Осуществляется передача данных об устройствах, которое
осуществляет выполнение исследования.
b. Обновление данных. Обновление ресурса разрешено только создателям данного
ресурса.
c. Получение данных об устройстве по запросу. МИС МО или РИС диагностического
отделения может запрашивать актуальную информацию о диагностическом
аппарате.
9. Обмен данными о PACS-серверах.
a. Добавление. Осуществляется передача данных о PACS-серверах ЦАМИ.
b. Обновление данных. Обновление ресурса разрешено только создателям данного
ресурса.
c. Получение данных о PACS- серверах по запросу. МИС МО или РИС
диагностического отделения может запрашивать актуальную информацию о
серверах PACS..
.
Базовая схема информационного взаимодействия приведена на рисунке ниже

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

 

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

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

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

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

Информационный обмен осуществляется в соответствии со стандартом FHIR® (Fast
Healthcare Interoperability Resources), разработанным организацией HL7. Используемая версия FHIR R4, 4.0.0. Подробное описание стандарта — http://hl7.org/fhir/ 
В качестве протокола взаимодействия используется RESTful AP (использование RESTпротокола в FHIR® – см. http://fhir-ru.github.io/http.html). Данные необходимо передавать в формате JSON, должен присутствовать http заголовок content-type: application/json.

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

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

Авторизационный токен выдается разработчику ИС администратором интеграционной платформы. Авторизационный токен должен соответствовать идентификатору информационной системы, указанному в идентификаторе передаваемого ресурса Для передачи данных в сервис необходимо передавать в заголовке сообщения заголовок вида content-type: application/json

Текстовая информация, передаваемая в запросах, должна передаваться в кодировке UTF8 (RFC 3629). Запрещается передача имени, отчества инициалами, а также записей вида «.», «нет», «нету» в случае, если отчество пациента отсутствует. Фамилия, имя, отчество должно начинаться с большой буквы, далее в нижнем регистре. Остальная текстовая информация передается регистром «Как в предложениях» или в нижнем регистре. Передача текста в верхнем регистре, за
исключением аббревиатур, не допускается. Все данные типа дата-время (кроме даты рождения пациента) следует передавать в сервис в формате YYYY-MM-DDThh:mm:ss[.SSS]±hh:mm (стандарт ISO8601). Допускается, но не рекомендуется передача данных в формате YYYY-MM-DD и YYYY-MM-DDThh:mm:ss[.SSS]Z. Дату рождения пациента следует передавать в формате YYYY-MM-DD

Ряд ключевых полей (например, DiagnosticReport.issued) сервис всегда возвращает в
формате YYYY-MM-DDThh:mm:ss±hh:mm, остальные поля не конвертируются и возвращаются в том формате, в котором были переданы в сервис

Идентификаторы, используемые для связки ресурсов в запросах, и ссылки на
существующие ресурсы в БД должны соответствовать требованиям, предъявляемым к GUID (RFC 4122), буквенные символы должны передаваться в нижнем регистре.

Идентификаторы для связки ресурсов в запросах должны начинаться с префикса urn:uuid:

Идентификаторы объектов (заявок, результатов, штрихкод) должны содержать только буквы и цифры, могут содержать символы двоеточия, запятой, тире, пробел, не могут содержать символы запятой, слеш любой, кавычки, спецсимволы.
OID справочников и OID передающей системы, передаваемые в параметрах “system”,
должны начинаться с префикса urn:oid: OID передающей системы, передаваемые в параметрах “display”, должны передаваться без префикса urn:oid:

Передача пустых значений вида parametrname: «» не допускается, за исключением
Order.detail.reference в результате без заявки

Ресурсы и бандлы, передаваемые в сервис, должны корректно валидироваться как JSON (RFC 8259) и соответствовать правилам стандарта FHIR по структуре и содержанию.

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

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

Ответы сервиса

Сервис осуществляет валидацию входных данных при вызовах любых методов. В ответ на запрос сервис возвращает HTTP код состояния и ответ. Основные коды и их значение указаны в таблице ниже.

Если валидация прошла успешно, то сервис возвращает успешный ответ (200, 201),
включающий в себя определенные параметры (в зависимости от типа запроса):
если передавался отдельный ресурс, возвращается переданный ресурс, в котором также передаются:

id — GUID созданного ресурса (присваивается при создании записи в БД, используется для формирования ссылки на ресурс),
meta — мета данные,
meta.versionId — версия id ресурса в сервисе ОДИИ,
meta.lastUpdated — дата-время последнего обновления ресурса

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

id — GUID Bundle в сервисе (присваивается при создании записи в БД, используется в
служебных целях)

entry – массив переданных в запросе ресурсов в виде entry, содержащих для каждого
ресурса параметры:

  • fullUrl (переданный в запросе параметр fullUrl преобразуется в ссылку на
    ресурс для дальнейшего запроса его в сервисе — на новый ресурс или
    ссылка на найденный в БД ресурс),
  • resource (непосредственно переданный ресурс),
  • response (status (201-created), location –ссылка на ресурс)

В случае, если передавался запрос информации, возвращается ресурс parameter,
содержащий массив данных (ресурсы и другая информация) в соответствии с типом запроса.

Если валидация прошла неуспешно, то сервис возвращает ошибку (400-504), а также параметр issue, содержащий массив с данными по обнаруженным ошибкам:
code — код ошибки
diagnostics — текст ошибки
location — массив параметров, в которых обнаружена данная ошибка.

Таблица 1. HTTP коды состояния
s

№ п/п Код Описание Примечание
1 200 Успешный ответ  
2 201 Успешный ответ, ресурс создан  
3 400 Ресурс не может быть проанализирован или не прошел валидацию по базовым правилам проверки FHIR Необходимо исправить ошибку в запросе
4 403 Ошибка авторизации (неверный токен) Необходимо использовать
токен, соответствующий
OID передающей системы
5 404 Тип ресурса не поддерживается / Метод не поддерживается Необходимо исправить
ошибку в запросе
6 405 Неверно сформирован запрос к сервису Необходимо исправить
ошибку в запросе
7 409 Попытка создания дубля данных (конфликт) Необходимо исправить
ошибку в запросе
8 415 Неподдерживаемый тип данных Необходимо передавать
данные в формате JSON, должен присутствовать
заголовок content-type: application/json
9 413 Тело запроса слишком велико Необходимо уменьшить
размер запроса
10 422 Ошибка валидации Необходимо исправить
ошибку в запросе
11 500 Сервис недоступен. Внутренняя ошибка сервиса Необходимо обратиться в
техническую поддержку
12 502 Сервис недоступен. Не включено серверное оборудование или не запущены программные компоненты модуля ИШ Необходимо обратиться в
техническую поддержку
13 503 Сервис недоступен. Не включено серверное оборудование или не запущены программные компоненты модуля ИШ Необходимо обратиться в
техническую поддержку
14 504 Сервис недоступен. Таймаут Необходимо обратиться в
техническую поддержку

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

Справочники, используемые в сервисе ОДИИ, опубликованы в «Сервисе Терминологии».
Описание сервиса Терминологии и правила взаимодействия с ним приведены по ссылке:
https://api.n3health.ru/terminologyservice/.
Для каждого справочника в Настоящем документе указан его OID (объектный
идентификатор). Перечень присвоенных корневых OID:

  • 1.2.643.5.1.13.2.1 — Корневой OID справочников, размещенных в реестре НСИ
    (http://nsi.rosminzdrav.ru/);
  • 1.2.643.2.69.1.1.1 – Корневой OID для справочников подсистемы НСИ
    Регионального фрагмента.

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

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

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

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

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

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

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

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

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

a. Передача информации от имени головного учреждения в данном случае не допускается.
b. При передаче заявки на исследование необходимо указывать то учреждение или подразделение (если зарегистрировано в справочнике), где проходит лечение пациент (открыт случай обслуживания и создана заявка). Параметры:
Заявка — Task.requester с Task.intent == original.order
Данные пациента — Patient.managingOrganization.
Случай обслуживания — Encounter.serviceProvider.

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

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

  1. Передача пациента (POST Patient).
  2. Обновление пациента (PUT Patient).
  3. Передача врача и квалификации (POST Practitioner, PractitionerRole).
  4. Обновление врача и квалификации (PUT Practitioner, PractitionerRole).
  5. Передача устройства (POST Device).
  6. Обновление устройства (PUT Device).
  7. Передача данных PACS-серверов и viewer (POST Endpoint).
  8. Обновление данных PACS-серверов и viewer (PUT Endpoint).
  9. Передача расписания (POST Schedule).
  10. Обновление расписания (PUT Schedule).
  11. Передача заявки (POST Bundle заявки).
  12. Передача результата (POST Bundle результата).
  13. Передача результата без заявки (POST Bundle результата без заявки).
  14. Запрос заявок / результатов (Task/_search).
  15. Отмена/отклонение заявки ($updatestatus)
  16. Запрос ресурсов (GET resource).

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

Для регистрации пациента в сервисе ОДИИ необходимо отправить запрос:
POST [hostname]/imaging/exlab/api/fhir/Patient?_format=json, в body передать ресурс Patient В ответе сервис возвращает json с созданным пациентом и его идентификатором в сервисе ОДИИ.

При передаче данных анонимных пациентов следует в ресурсе Patient передавать
параметр name.use = “anonymous”, не передавать никакие идентификаторы, кроме
идентификатора в МИС/РИС, не передавать адрес пациента. Параметры name.given, name.family должны содержать произвольные значения, например «Анонимный».

Уникальность пациента проверяется по совокупности параметров identifier.value
(идентификатор пациента в МИС), identifier.assigner.display (OID передающей системы), managingOrganization (передающая организация). Многократная передача одного и того же пациента из одной и той же МИС с разными набором ключевых параметров категорически запрещена. Передача разных пациентов с одним и тем же набором ключевых параметров категорически запрещена.

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

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 id string 1..1 усл.

GUID ресурса в сервисе. Присвоенный
сервисом идентификатор при
регистрации ресурса.

усл.: обязательно передается при обновлении ресурса методом PUT

3 identifier identifier 1..*

Идентификатор пациента. Указывает код пациента в МИС, РИС, ДУЛ пациента, полисы, СНИЛС.

Обязательно к передаче Должен передаваться хотя бы идентификатор в ИС (identifier.system
1.2.643.5.1.13.2.7.100.5).

3.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.Х), где Х = код
    документа в справочнике
    1.2.643.2.69.1.1.1.6.
3.2 identifier.value string 1..1

Значение для идентификатора или для документа.

  • Для идентификатора в МИС/РИС указывается [идентификатор в
    МИС/РИС] (UK)
  • Для паспорта и свидетельства о
    рождении указывается
    [Серия]:[Номер]
  • Для СНИЛС, страхового полиса
    указывается:
  • [Серия полиса]:[Номер полиса] –
    для полиса старого образца
  • [Номер полиса] – для СНИЛС, полиса нового образца и временного свидетельства

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

  • серии и номера документа для
    документов Паспорт гражданина РФ,
    Свидетельство о рождении РФ, Загранпаспорт гражданина РФ по маске, указанной в справочнике
    1.2.643.5.1.13.13.99.2.320
    «Классификатор документов,
    удостоверяющих личность гражданина Российской Федерации»;
  • Номера ЕНП по контрольной сумме;
  • Номера СНИЛС по правилам ПФР РФ
3.3 identifier.period Period 0..1

Период действия для паспорта и полиса.

Вложенные параметры:

  1. start — дата начала периода
  2. end — дата окончания периода
3.4 identifier.assign
er.display
string 1..1
  • Указывается OID передающей ИС1 для идентификатора пациента (UK)
  • Для ДУЛ – наименование выдавшей организации.
  • Для полиса ОМС любого типа
    указывается
    1.2.643.5.1.13.2.1.1.635.[код
    страховой компании]
  • Для полиса ДМС – наименование СМО ДМС.
  • Для СНИЛС – «ПФР».
4 telecom ContactPoint 0..* Контактные данные пациента.
Вложенные параметры:
1. system — вид контактных
данных. Допустимые параметры phone (телефон), email (электронная почта)
2. use – тип контакта. Допустимые
параметры home (домашний),
work (рабочий), mobile (мобильный).
3. value — значение номера
телефона или адрес электронной почты 
Все параметры обязательные (1..1)
5. name HumanName 1..1 Информация о ФИО пациента.
5.1 name.family string 1..1 Фамилия
5.2 name.given string 1..2 Сначала указывается Имя. Отчество.
5.3 name.use code 0..1 Принимает значение “anonymous” для передачи данных по анонимному
пациенту.
6 gender code 1..1 Код пола пациента (справочник FHIR.
OID: 1.2.643.2.69.1.1.1.40).
7 birthDate Date 1..1 Дата рождения. Формат: yyyy-MM-dd.
8 extension   0..1

Расширение формата для передачи
места рождения пациента.
Вложенные параметры:
1. url — указывается ссылка на
описание расширения
http://hl7.org/fhir/
StructureDefinition/birthplace,

2. valueAddress.text — место рождения так, как указано в паспорте.

9 address Address 0..*

Информация об адресе пациента

9.1 address.extension   0..4

Расширение формата для передачи
дополнительных данных адреса:

— код вида места жительства пациента
(город/село). В параметре url
указывается ссылка на справочник
http://api.n3med.ru/api/fhir/n3extension
-residenceclasscode/ в параметре
valueCode код места жительства по
справочнику OID 1.2.643.5.1.13.13.11.1042;

— код ФИАС адреса. В параметре url
указывается ссылка
http://api.n3med.ru/api/fhir/n3extension
-aoguid/ , в параметре valueString
AOGUID адресного объекта по ФИАС»; — код ФИАС дома. В параметре url
указывается ссылка
http://api.n3med.ru/api/fhir/n3extension
-houseguid/ , в параметре valueString
HOUSEGUID здания по ФИАС»;

— номер квартиры. В параметре url указывается ссылка
http://api.n3med.ru/api/fhir/n3extension-flatid/ , в параметре valueString номер
квартиры»

9.2 address.use code 1..1

Тип адреса (справочник FHIR. OID:
1.2.643.2.69.1.1.1.41)

    • home — Адрес проживания.
    • temp — Адрес регистрации.

 

9.3 address.text string 1..1

Адрес строкой

9.4 address.line string 0..1

Улица, номер дома, номер корпуса,
номер квартиры (массив), необходимо придерживаться порядка:

Первая строка в массиве line всегда
улица

Если строк две, то вторая — дом
Если строк три, то вторая— дом, третья
квартира
Если четыре, то вторая дом, третья
корпус, четвертая квартира
Префиксы (ул., д., кор., стр., кв.)
должны отделяться от значения точкой или точкой и пробелом. Пример: «line»:
[«ул. Оптиков», «д. 6″,»кв. 220»

9.5 address.state string 0..1

Регион. Указывается двузначный код
субъекта РФ по справочнику
1.2.643.5.1.13.13.99.2.206

9.6 address.city string 0..1

Город

9.7 address.district string 0..1

Район

9.8 address.postalCode string 0..1

Почтовый индекс

10 contact Backbone
Element
0..*

Контактные данные представителя
пациента

10.1 contact.telecom ContactPoint 1..*

Вложенные параметры:

  • system — вид контактных данных. Допустимые параметры phone (телефон), email (электронная почта) 
  • use – тип контакта. Допустимые параметры home (домашний),
    work (рабочий), mobile (мобильный).
  • value — значение номера телефона или адрес электронной почты

Все параметры обязательные (1..1)

11 managingOrganization reference
(Organiza
tion)
1..1

Ссылка на организацию в формате
Organization/GUID, где GUID –
идентификатор организации по
справочнику 1.2.643.2.69.1.1.1.64 (UK)

12 link   0..1

Информация о представителе
пациента

12.1 link.type code 1..1

Тип ссылки, всегда передается “refer”

12.2 link.other Reference(Patient) 1..1

Ссылка на ресурс Patient в БД,
описывающий представителя
пациента

Для корректной работы федеральных сервисов СЭМД, РЭМД при передаче пациента
обязательно должен передаваться СНИЛС

Для корректной работы смежных сервисов N3 (MPI, Портал врача, Личный кабинет
пациента) при передаче пациента должны передаваться номер полиса и СНИЛС

СНИЛС и номер полиса пациента могут проверяться сервисом на совпадение контрольной суммы.

При передаче заведомо некорректных данных пациента (неизвестные пациенты,
новорожденные без имени и др.) к имени пациента необходимо добавлять параметр name.use == temp. В случае появления информации о корректных данных необходимо обновить данные пациента в сервисе методом PUT Patient, исключив указанный параметр.
При передаче данных анонимного пациента к имени пациента необходимо добавлять параметр name.use == anonymous. Для анонимного пациента запрещена передача персонализированных данных (адрес, номер полиса, паспорта, СНИЛС)
Для корректной передачи данных в случаях, когда лечение производится за счет средств ОМС по полису представителя, необходимо передавать данные следующим образом:
— представитель пациента передается как отдельный ресурс Patient, для него передается его полис
— для пациента в параметре Patient.link.other указывается ссылка на ресурс Patient,
описывающий представителя
— в заявке на исследование указывается источник финансирования «Оплата по полису представителя»

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

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

Важно: обновление ресурса разрешено только создателям данного ресурса.
Для обновления пациента необходимо отправить запрос PUT [hostname]/imaging/exlab/api/fhir/Patient/[GUID]?_format=json, в body передать ресурс Patient.
Требования к GUID: GUID пациента в URL должен соответствовать id, указанному в
запросе.
В ответе сервис возвращает json с обновленным пациентом и его идентификатором в
сервисе ОДИИ.

Передача врача и квалификации (POST Practitioner, PractitionerRole)

Для регистрации врача в сервисе ОДИИ необходимо отправить два запроса
последовательно
POST [hostname]/Practitioner?_format=json, в body передать ресурс Practitioner
POST [hostname]/PractitionerRole?_format=json, в body передать ресурс PractitionerRole.
В ответах сервис возвращает json’ы с созданными ресурсами и их идентификаторами в сервисе ОДИИ.
Данные СНИЛС, идентификатор врача в ИС должны передаваться в параметре identifier.
Уникальность врача проверяется по совокупности параметров identifier.value
(идентификатор врача в МИС и СНИЛС), identifier.assigner.display (OID передающей системы).
Уникальность квалификации врача проверяется по совокупности параметров
practitionerRole.Organization (передающая организация), practitionerRole.specialty (код
специальности) и practitionerRole.role (код должности). Многократная передача одного и того же врача из одной и той же МИС с разными набором ключевых параметров категорически запрещена. Передача разных врачей с одним и тем же набором ключевых параметров категорически запрещена. Передача врача без СНИЛС категорически запрещена.

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

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 id string 1..1 усл.

GUID ресурса в сервисе. Присвоенный
сервисом идентификатор при
регистрации ресурса.

усл.: обязательно передается при обновлении ресурса методом PUT

3 identifier identifier 1..*

Идентификатор врача (идентификатор в МИС/РИС и СНИЛС). Должны передаваться оба идентификатора.

3.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).

3.2 identifier.value string 1..1 Значение для идентификатора или
для СНИЛС. (UK)
3.3 identifier.assign
er.display
string 1..1
  • Указывается OID передающей ИС для идентификатора врача (UK)
  • Для СНИЛС – «ПФР».
4 active boolean 1..1 Признак активности записи. true – запись активна, может использоваться, false – запись
неактивна, не может использоваться
5. name HumanName 1..1 ФИО врача
5.1 name.family string 1..1 Фамилия
5.2 name.given string 1..2 Сначала указывается Имя. Отчество.

Для корректной работы федеральных сервисов СЭМД, РЭМД при передаче врача должен передаваться СНИЛС. СНИЛС врача, должность врача, МО должны совпадать с соответствующими данными работника в ФРМР.
СНИЛС врача может проверяться сервисом ОДИИ на совпадение контрольной суммы.

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

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 id string 1..1 усл.

GUID ресурса в сервисе. Присвоенный
сервисом идентификатор при
регистрации ресурса.

усл.: обязательно передается при обновлении ресурса методом PUT

3 active boolean 1..1

Признак активности записи

4 practitioner Reference(Prac
titioner)
1..1

Ссылка. Соотнесение с врачом.
Должна указываться ссылка на
существующий Practitioner в БД (UK)

5 organization Reference(Orga
nization)
1..1

Ссылка на организацию, в которой
работает врач в формате
Organization/GUID, где GUID –
идентификатор организации по
справочнику 1.2.643.2.69.1.1.1.64. (UK)

6 code CodeableConcept 1..1

Код должности врача (Номенклатура
должностей медицинских работников и фармацевтических работников). (UK)
Вложенные параметры:
1. coding.system — указывается
OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1002 или
1.2.643.5.1.13.13.11.1102 – в
зависимости от региональных
настроек)
2. coding.version — указывается
версия справочника в сервисе
Терминологии,
3. coding.code — указывается код значения из справочника.

7 specialty CodeableConcept 1..1

Код специальности врача
(Номенклатура специальностей
специалистов с высшим и
послевузовским медицинским и
фармацевтическим образованием в
сфере здравоохранения). (UK)
Вложенные параметры:
1. coding.system — OID
справочника в сервисе
Терминологии
(1.2.643.5.1.13.13.11.1066),
2. coding.version — версия
справочника в сервисе
Терминологии,
3. coding.code — код значения из
справочника.

Обновление врача и квалификации (PUT Practitioner,PractitionerRole)

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

Передача устройства (POST Device)

Для регистрации устройства в сервисе ОДИИ необходимо отправить запрос
POST [hostname]/Device?_format=json, в body передать ресурс Device
В ответе сервис возвращает json с созданным устройством и его идентификатором в
сервисе ОДИИ.

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

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 id string 1..1 усл.

GUID ресурса в сервисе. Присвоенный
сервисом идентификатор при
регистрации ресурса.

усл.: обязательно передается при обновлении ресурса методом PUT

3 identifier Identifier 1..1

Идентификатор устройства. Указывается код
устройства в МИС / РИС

3.1 identifier.system uri 1..1

OID передающей ИС3 (UK)

3.2 identifier.value string 1..1

Указывается идентификатор устройства (AE Title). Не более 16 символов. (UK)

4 type CodeableConcept 1..1

Тип оборудования.
Вложенные параметры:
1. coding.system — OID справочника в
сервисе Терминологии
(1.2.643.5.1.13.13.11.1071),
2. coding.version — версия справочника в
сервисе Терминологии,
3. coding.code — код значения из
справочника.

5 specialization
.systemType
CodeableConcept 1..*

Тип модальности.
Вложенные параметры:
1. coding.system — OID справочника в
сервисе Терминологии
(1.2.643.2.69.1.1.1.121),
2. coding.version — версия справочника в сервисе Терминологии,
3. coding.code — код значения из
справочника

6 status code 1..1

Состояние устройства. Статус доступности устройства.
Передается всегда active или inactive

7 manufacturer string 0..1

Название производителя устройства.

8 distinctIdentifier string 1..1

Инвентарный номер устройства (обязателен для
передачи в ВИМИС)

9 serialNumber string 0..1

Серийный номер устройства (обязателен для передачи в ВИМИС)

10 deviceName BackboneElement 1..*

Вложенные параметры:
1. name — Имя
2. type — Передается всегда manufacturername

11 version.value string 0..1

Номер версии.

12 manufactureDate dateTime 0..1

Дата производства.

13 expirationDate dateTime 0..1

Дата истечения срока годности для устройства.

14 udiCarrier string 0..1

Штрих-код уникального идентификатора устройства (UDI).

14.1 carrierHRF string 1..1

Строковое значение штрих-кода уникального идентификатора устройства (UDI).

14.2 barcode code 1..1

Тип уникального идентификатора устройства (всегда передается barcode).

15 property.type CodeableConcept 0..1

Тип устройства
Вложенные параметры:
1. coding.userSelected — поддержка
интеграции с worklist
true — оборудование интегрировано с worklist
false — оборудование НЕ интегрировано с worklist

16 owner Reference
(Organization)
1..1

Ссылка на организацию, которая ответственна за устройство, в формате Organization/GUID, где GUID – идентификатор организации по
справочнику 1.2.643.2.69.1.1.1.64 (UK)

17 url uri 0..1

Адрес (IP адрес с указанием порта)

Обновление устройства (PUT Device)

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

Передача данных PACS-серверов и viewer (POST Endpoint)

Для регистрации PACS-серверов (центральных мест хранения изображений и протоколов исследований) в сервисе ОДИИ необходимо отправить запрос
POST [hostname]/Endpoint?_format=json. в body передать ресурс Endpoint
В ответе сервис возвращает json с созданным ресурсом и его идентификатором в сервисе ОДИИ.

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

Ресурс Endpoint предназначен для передачи данных PACS, где хранится исследование, и ссылки web-viewer для просмотра исследования, назначение ресурса определяется типом соединения (connectionType).
Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 id string 1..1 усл.

GUID ресурса в сервисе. Присвоенный
сервисом идентификатор при
регистрации ресурса.

усл.: обязательно передается при обновлении ресурса методом PUT

3 identifier Identifier 1..1

Идентификатор PACS. Указывается AE
сервера. Не более 16 символов

3.1 identifier.system uri 1..1

OID передающей ИС4(UK)

3.2 identifier.value string 1..1

Указывается идентификатор устройства (AE Title). Не более 16 символов. (UK)

4 status code 1..1

Статус ресурса (справочник FHIR. OID
справочника в сервисе Терминологии:
2.16.840.1.113883.4.642.1.495).
active — доступный для получения данных

off — недоступен для получения данных

5 connectionType Coding 1..1

Тип соединения. (UK)
Вложенные параметры:
1. system — OID справочника в сервисе Терминологии
(2.16.840.1.113883.4.642.1.1140),
2. version — версия справочника в сервисе Терминологии,
3. code — код значения из справочника.
a. ihe-iid — для передачи адреса
web viewer
b. dicom-wado-uri — для передачи адреса PACS

6 managingOrganization Reference(O
rganization)
1..1

Ссылка на организацию, которой принадлежит точка доступа, в формате Organization/GUID, где GUID – идентификатор организации по
справочнику 1.2.643.2.69.1.1.1.64. (UK)

7 address url 1..1

Адрес PACS (IP адрес с указанием порта) для
получения исследований.
При передаче данных PACS-серверов (dicomwado-uri) Endpoint.address содержит строку:
1. ИЛИ с ip адресом. Схема: X.X.X.X, где X — число
2. ИЛИ с ip адресом и портом. Схема:
X.X.X.X:X, где X – число
При передаче данных вьюера (ihe-iid) Endpoint.address содержит строку, по которой вызывается оболочка вьюера. Адрес должен
заканчиваться /. Значение не должно содержать пробелов.

8 header string 0..2

Информация для вызова вьюера. В первом элементе указывается средняя часть ссылки (между URL из address и StudyUID), во втором
элементе указывается окончание ссылки (после StudyUID)
Первый элемент не должен начинаться с /, должен заканчиваться /. Второй элемент не
должен начинаться с /. Значения не должны содержать пробелов.

Правила формирования URL для вызова вьюера
В случае, если для выполненного исследования есть техническая возможность вызова вьюера для просмотра изображения по StudyUID выполненного исследования, информация о таком вьюере должна быть особым образом передана в ресурсе Endpoint. По этим данным сторонняя информационная система сможет сформировать ссылку для вызова вьюера. Ссылка должна формироваться следующим образом: [PicsLinkEndpoint][PicsLinkMiddle][StudyUID]+[PicsLinkEnd],
где:
[PicsLinkEndpoint]- корневая ссылка на вьюер (URL);
[PicsLinkMiddle] — средняя часть ссылки;
[StudyUID] — идентификатор исследования;
[PicsLinkEnd]- окончание ссылки.

Настройки вьюера передаются в параметре header ресурса Enpoint и представляют собой массив кратностью 0..2, при этом в первом элементе массива хранится PicsLinkMiddle, во втором элементе массива хранится PicsLinkEnd.
При этом (в зависимости от наличия или отсутствия параметров) ссылка может формироваться в следующих вариантах:
[PicsLinkEndpoint]+[StudyUID]
[PicsLinkEndpoint][PicsLinkMiddle][StudyUID]
[PicsLinkEndpoint][PicsLinkMiddle][StudyUID]+[PicsLinkEnd]
Пример передачи ресурса Endpoint для передачи данных viewer


{
"resourceType": "Endpoint",
"identifier": [
{
"system": "urn:oid:1.2.643.2.69.1.2.6",
"value": "AE_PACS"
}
],
"status": "active",
"connectionType":
{
"system": "urn:oid:2.16.840.1.113883.4.642.1.1140",
"version": "1",
"code": "ihe-iid"
},
"managingOrganization": {
"reference": "Organization/a83b0b1f-46aa-46d6-8d51-77c5a6cdc3c9"
},
"address": "http://10.16.22.41/",
"header" : ["#/viewer/image-view/","/PICKSYS%20PACS"]
}

 

В приведенном выше примере для исследования со StudyUID
1.2.410.200049.2.47462040765632.1.1.20180911130148009.30 сторонняя информационная система должна будет сформировать ссылку http://10.16.22.41/#/viewer/imageview/1.2.410.200049.2.47462040765632.1.1.20180911130148009.30/PICKSYS%20PACS

Обновление данных PACS-серверов и viewer (PUT Endpoint)

В сервисе ОДИИ есть возможность обновить информацию о PACS-сервере. При
обновлении данных должна передаваться полная информация ресурса. Для получения текущей информации по ресурсу в сервисе необходимо запросить ресурс (операция GET), а потом передать его со всеми параметрами, в том числе и не изменившимися (операция PUT).
Обновление ресурса разрешено только создателям данного ресурса.
При обновлении ресурса необходимо отправить запрос:
PUT [hostname]/Endpoint/[GUID]?_format=json, в body передать ресурс Endpoint
В ответе сервис возвращает json с обновленными данными PACS-сервера и его
идентификатором в сервисе ОДИИ.

Передача расписания (POST Schedule)

Ресурс Schedule содержит данные расписания устройства (Device). Метод предназначен для подтверждения заявки Целевой МО и дальнейшего формирования задания в worklist. В ресурсе передаются следующие данные:
1. Идентификатор направления (УО/ОДИИ)
2. Планируемая дата проведения исследования
3. Ссылка на устройство, на котором планируется выполнение исследования
4. Тип модальности устройства, на котором планируется выполнение исследования
Для передачи данных расписания устройств в сервис ОДИИ необходимо отправить запрос POST [hostname]/Schedule?_format=json, в body передать ресурс Schedule
В ответе сервис возвращает json с созданным ресурсом и его идентификатором в сервисе ОДИИ.

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

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 id string 1..1 усл.

GUID ресурса в сервисе. Присвоенный
сервисом идентификатор при
регистрации ресурса.

усл.: обязательно передается при обновлении ресурса методом PUT

3 identifier Identifier 1..1

Данные идентификатора

3.1 identifier.system uri 1..1

OID передающей ИС(UK)

3.2 identifier.value string 1..1

Идентификатор заявки, по которой
передается расписание устройства
(ACSN) Должен указываться ACSN
существюущей в сервисе заявки (UK)

3.3. identifier.type CodeableConcept 1..1

Тип идентификатора.
Вложенные параметры:
1. coding.system — OID справочника
в сервисе Терминологии
(1.2.643.2.69.1.1.1.122),
2. coding.code — ACSN
3. coding.version — актуальная
версия

3.4 identifier.assigner Reference(Or
ganization)
1..1

Ссылка на организацию, в которой
планируется исследование, в формате Organization/GUID, где GUID – идентификатор организации по
справочнику 1.2.643.2.69.1.1.1.64 . (UK)

4 active boolean 1..1

Признак активной записи. Всегда == true

5 serviceType CodeableConcept 1..1

Тип модальности устройства
(Schedule.actor).
Вложенные параметры:
1. coding.system — OID справочника в
сервисе Терминологии
(1.2.643.2.69.1.1.1.121),
2. coding.version — версия справочника в сервисе Терминологии,
3. coding.code — код значения из
справочника. Должна быть в списке модальностей, переданных для данного устройства

6 actor Reference(De
vice)
1..1

Ссылка на устройство, на котором
планируется выполнить исследование

7 planningHorizon Period 1..1

Планируемая дата проведения
исследования. Вложенные параметры:
1. start — дата-время исследования

Обновление расписания (PUT Schedule)

В сервисе ОДИИ есть возможность обновить информацию о расписании устройства.
Обновление ресурса разрешено только создателям данного ресурса.
При обновлении ресурса необходимо отправить запрос:
PUT [hostname]/Schedule/[GUID]?_format=json, в body передать ресурс Schedule
В ответе сервис возвращает json с обновленными данными расписания и его
идентификатором в сервисе ОДИИ

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

Передача заявки производится с помощью передачи в сервис ресурса Bundle. Ресурс Bundle является контейнером, содержащий в себе набор ресурсов характерных для передаваемых данных. Для передачи Bundle необходимо отправить запрос: POST [hostname]?_format=json, в body передать ресурс Bundle. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ОДИИ.
Уникальность заявки проверяется по совокупности параметров ресурса Task identifier.system (OID передающей системы), identifier.value (идентификатор заявки в МИС), requester (передающая  организация). Многократная передача одной и той же заявки (с одним и тем же набором ключевых параметров) запрещена (допускается после отмены заявки).

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 type code 1..1

Тип Bundle Всегда передается transaction

3 entry BackboneElement 1..*

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

3.1 entry.fullUr uri 1..1

URI ресурса (UUID). Используется для связи ресурсов внутри Bundle

3.2 entry.resource Recourse 1..1

Ресурс. Содержит параметры передаваемого ресурса

3.3 entry.request BackboneE
lement
1..1

Вложенные параметры: method — HTTP действие. Всегда передается POST

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

Ресурс Ссылки на другие ресурсы Описание
1 Task ● Task.for – ссылка на
Patient
● Task.requester – ссылка на
Organization
● Task.identifier.assigner –
ссылка на Organization
● Task.owner – ссылка на
Organization
● Task.focus – ссылка на
Servicerequest
В ресурсе указывается общая информация о заявке на проведение исследования:
● идентификатор и дата заявки,
● данные об организации, сделавшее
назначение
● данные о целевой организации
● данные пациента, которому назначено
исследование,
● информация о назначении.
2 Patient ●Patient.managingOrganizati
on – ссылка на Organization
В ресурсе указывается информация о
пациенте. Может не передаваться,
указывается как ссылка на существующий ресурс.
3 Practitioner   В ресурсе указывается информация о враче: для передачи данных об авторе заявки и врачах, которые сделали назначение пациенту. Может не передаваться, указывается как ссылка на существующий ресурс.
4 Practitioner
Role
●PractitionerRole.organizatio
n – ссылка на Organization
●PractitionerRole.practitioner
— ссылка на врача
 
5 Encounter ● Encounter.diagnosis.conditi
on – ссылка на Condition,
● Encounter.subject – ссылка
на Patient
● Encounter.serviceProvider
– ссылка на Organization
В ресурсе указывается
● информация о случае обслуживания, в
рамках которого назначено исследование,
● информация о диагнозе пациента.
6 ServiceRequest

● ServiceRequest.subject –
ссылка на Patient
● ServiceRequest.requester –
ссылка на PractitionerRole
● ServiceRequest.encounter
– ссылка на Encounter

● ServiceRequest.supportingI
nfo – ссылка на
Condition/Observation

В ресурсе указывается подробная
информация о заявке:
● назначение (список исследований),
● данные врача, сделавшего это
назначение,
● информация о случае обслуживания,

● дополнительная информация о состоянии пациента
● информация об источнике финансирования

7 Observation   В ресурсе указывается информация о
состоянии пациента: рост, вес
8 Condition ● Condition.subject – ссылка
на Patient
В ресурсе указывается информация о
состоянии пациента: диагнозы.

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

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


п/п
Ресурс Кратность Операции Возможность использования
ссылки на ресурс
1 Task 1..1 Создание Ресурс должен всегда передаваться в составе Bundle
2 ServiceRequest 1..1 Создание Ресурс должен всегда передаваться в составе Bundle
3 Patient 0..1 ● Создание
● Обновление
Ресурс может передаваться в составе Bundle.
Если ресурс не передается, то в параметрах указывается ссылка на уже существующий в БД ресурс
4 PractitionerRole 0..1 ● Создание
● Обновление
Ресурс может передаваться в составе Bundle.
Если ресурс не передается, то в параметрах указывается ссылка на уже существующий в БД ресурс
5 Practitioner 0..1 ● Создание
● Обновление
Ресурс может передаваться в составе Bundle.
Если ресурс не передается, то в параметрах указывается ссылка на уже существующий в БД ресурс
6 Encounter 0..1 ● Создание
● Обновление
Ресурс должен всегда передаваться в составе Bundle
7 Observation 0..* Создание Ресурс должен всегда передаваться в составе Bundle
8 Condition 0..* Создание Ресурс должен всегда передаваться в составе Bundle

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

Task заявки

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 identifier Identifier 1..1 Идентификатор заявки в МИС.
2.1 identifier.system uri 1..1 В качестве кодовой системы указывается OID
передающей системы (UK)
2.2 identifier.value string 1..1 Идентификатор заявки в ИС. Должен быть уникален для данной МО (UK)
2.3 identifier.use code 0..1 Признак первичного / повторного направления.
usual – первично secondary – повторно
Если параметр отсутствует, направление первичное
2.4 identifier.type CodeableConcept 0..0 Не передается. В ответе сервис вернет
дополнительный идентификатор (accession
number, не более 16 символов) со следующим
типом идентификатора.
Вложенные параметры:
1. coding.system — OID справочника в
сервисе Терминологии
(1.2.643.2.69.1.1.1.122),
2. coding.code — ACSN
3 status code 0..0 Не передается. Сервис вернет статус заявки в
ответе.
Статус (справочник FHIR. OID справочника в
сервисе Терминологии:
2.16.840.1.113883.4.642.1.791)
4 intent code 1..1 Назначение (справочник FHIR. OID справочника в сервисе Терминологии:
2.16.840.1.113883.4.642.1.114). Для Bundle заявки на исследование передается original-order (UK)
Для Bundle заявки на расшифровку исследования
передается filler-order (UK)
5 focus Reference
(ServiceRequest)
1..1 Для заявки на исследование (original-order) передается соотнесение с клинической частью (ServiceRequest). Должен передаваться ресурс
ServiceRequest в Bundle.
6 based-on Reference
(Task)
1..1 усл. Для заявки на расшифровку исследования (fillerorder) дополнительно передается соотнесение с Task результата, содержащего сведения об
изображении. Должна передаваться ссылка на
существующий ресурс Task.
7 for Reference
(Patient)
1..1 Ссылка. Соотнесение с пациентом. Должен
передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient.
8 authoredOn dateTime 1..1 Дата формирования направления (yyyy-MMddTHH:mm:sszzz).
9 requester Reference
(Organization)
1..1 Ссылка. Соотнесение с направляющей МО.
Должна указывается ссылка на существующий Organization(UK)
10 owner Reference
(Organization)
1..1 Ссылка на организацию, в которой будет выполняться исследование, в формате
Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64

ServiceRequest

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 status Code 0..0 Не передается. Сервис вернет статус ресурса в ответе.
Статус (справочник FHIR. OID справочника в сервисе
Терминологии: 2.16.840.1.113883.4.642.1.112).
3 intent Code 1..1 Назначение (справочник FHIR. OID справочника в сервисе Терминологии:
2.16.840.1.113883.4.642.1.114). Для Bundle заявки всегда передается filler-order
4 priority Code 0..1 Приоритет выполнения (отметка срочности).
Согласно справочнику FHIR
2.16.840.1.113883.4.642.1.116
5 code CodeableConcept 1..1 Сведения о запрашиваемой услуге.
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1471, для
заявки на описание снимка
1.2.643.5.1.13.13.11.1070),
2. coding.version — версия справочника в сервисе
Терминологии,
3. coding.code — код значения из справочника.
6 orderDetail CodeableConcept 1..1 Источник финансирования.
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.2.69.1.1.1.32),
2. coding.version — версия справочника в сервисе
Терминологии,
3. coding.code — код значения из справочника.
4. coding.display — при необходимости может быть
указана дополнительная информация об оплате,
например – данные договора при оказании услуг
на платной основе или программа ДМС
7 subject Reference
(Patient)
1..1 Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient
8 encounter Reference
(Encounter)

1..1 усл.

Ссылка. Соотнесение со случаем обслуживания.
Должен передаваться ресурс Encounter в Bundle или
указывается ссылка на существующий Encounter
Для заявки на описание снимка не обязателен
9 occurrenceTiming Timing

0..1

Данные о том, когда должно быть выполнено исследование.
Вложенные параметры:
1. event (DateTime) — дата и время выполнения.
2. repeat.duration (decimal) — продолжительность
выполнения исследования в минутах.
10 requester Reference
(PractitionerRole)

1..1

Ссылка на ресурс PractitionerRole, описывающий квалификацию врача, сделавшего назначение.
Должен передаваться ресурс PractitionerRole в Bundle и указываться ссылка на передаваемый ресурс, или
указывается ссылка на существующий PractitionerRole
11 performerType CodeableConcept

0..1

Тип модальности устройства
(ServiceRequest.performer) для выполнения запрошенной услуги.
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.2.69.1.1.1.121),
2. coding.version — версия справочника в сервисе
Терминологии,
3. coding.code — код значения из справочника.
12 performer Reference
(Device)

0..1

Ссылка. Соотнесение с устройством, на котором
должно быть выполнено исследование. Должна
указываться ссылка на существующий в БД ресурс
Device
13 supportingInfo Reference
(Observation|Condition)

0..*

Ссылка.
Соотнесение с описанием состояния пациента (рост,
вес, иные дополнительные данные). Должен передаваться ресурс Observation/ Condition в Bundle
Ссылка на печатную форму направления или иной
документ в формате PDF, CDA и др., разрешенный в настройках сервиса. Должен передаваться ресурс Binary в Bundle (см. описание Binary результата)
Для заявки на описание снимка – ссылка на ресурс
ImagingStudy, содержащий сведения об изображении
  bodySite CodeableConcept

1..*

Область исследования.
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1477),
2. coding.version — версия справочника в сервисе
Терминологии,
3. coding.code — код значения из справочника.
14 note Annotation

0..1

Примечание к заявке

Patient

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

Practitioner

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

PractitionerRole

Ресурс PractitionerRole предназначен для передачи информации о квалификации врача. В этом ресурсе указывается:
● Специальность
● Должность
● Место работы
● Врач
Параметры ресурса PractitionerRole приведены в разделе передачи данных врача

Encounter

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 identifier Identifier 1..1 Идентификатор случая обслуживания в МИС и
детальная информация по карте пациента
2.1 identifier.system uri 1..1 Пространство имён идентификатора — указывается OID передающей системы
2.2 identifier.value string 1..1 Идентификатор случая обслуживания в МИС
2.3 identifier.type string 1..1 Тип карты (обязателен для ВИМИС):
1. system — OID справочника в сервисе Терминологии
(1.2.643.5.1.13.13.11.1507),
2. version — версия справочника в сервисе Терминологии,
3. code — код значения из справочника
2.4 identifier.period.start datetime 1..1 Дата создания карты (обязательно для ВИМИС)
2.5 identifier.assigner.referense string 1..1 Ссылка на организацию , в которой открыта карта, в
формате Organization/GUID, где GUID – идентификатор организации по справочнику
1.2.643.2.69.1.1.1.64 (обязательно для ВИМИС)
3 status code 1..1 Статус случая обслуживания (справочник FHIR. OID
справочника в сервисе Терминологии:
2.16.840.1.113883.4.642.1.247). Передается «inprogress» для открытого случая обслуживания, «finished» для закрытого случая.
4 class Coding 1..1 Класс случая обслуживания (справочник FHIR. OID
справочника в сервисе Терминологии:
2.16.840.1.113883.1.11.13955).
Вложенные параметры:
1. system — OID справочника в сервисе Терминологии (2.16.840.1.113883.1.11.13955),
2. version — версия справочника в сервисе Терминологии,
3. code — код значения из справочника. Передается EMER для скорой помощи, IMP для ДС
при стационаре, AMB для амбулаторного обслуживания, SS для ДС при поликлинике, HH на дому, ACUTE круглосуточный стационар
5 type CodeableConcept 1..*

Тип случая обслуживания (региональный справочник
типов случая обслуживания):
1. В параметре system указывается OID справочника
в сервисе Терминологии (1.2.643.2.69.1.1.1.35),
2. В параметре version указывается версия
справочника в сервисе Терминологии,
3. В параметре code указывается код значения из справочника
Дополнительно могут передаваться:
1. Форма оказания медицинской помощи по справочнику 1.2.643.5.1.13.13.11.1551

2. Вид оказания медицинской помощи по справочнику
1.2.643.5.1.13.13.11.1034
3. Условия оказания медицинской помощи по
справочнику 1.2.643.5.1.13.13.99.2.322
4. Место оказания медицинской помощи по справочнику 1.2.643.5.1.13.13.11.1008
5. Профиль медицинской помощи по справочнику
1.2.643.5.1.13.13.11.1119
6. Иные характеристики случая обслуживания по справочникам ТФОМС, участок, по которому осуществляется обслуживание, код контингента,
код вида поступления.
Передача дополнительных данных (обязательность,
используемые справочники) определяется на уровне
региона и настраивается по требованию регионального МИАЦ

6 subject reference
(Patient)
1..1 Ссылка. Соотнесение с пациентом. Должен
передаваться ресурс Patient в Bundle или указывается
ссылка на существующий Patient.
7 period Period 0..1 Даты случая.
Вложенные параметры:
1. start — дата начала случая.
2. end — дата окончания случая.
8 participant.individual reference
(PractitionerRole)
0..1 Ссылка на направляющего врача. Должен передаваться ресурс PractitionerRole в Bundle или указывается ссылка на существующий PractitionerRole.
9 reasonCode CodeableConcept 0..1 Цель посещения (региональный справочник целей
посещения).
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.2.69.1.1.1.19),
2. coding.version — версия справочника в сервисе
Терминологии,
3. coding.code — код значения из справочника
10 diagnosis.condition Reference
(Condition)
1..* Ссылка. Соотнесение с диагнозами пациента. Должен
передаваться ресурс Condition в Bundle.
11 serviceProvider Reference
(Organization)
1..1 Ссылка. Соотнесение с кодом МО (или отделения). Должна указываться ссылка на существующую в БД Organization

Observation заявки

Ресурс Observation предназначен для передачи информации о состоянии пациента. В этом ресурсе может указываться рост (в сантиметрах), вес (в килограммах) пациента, а также другие необходимые параметры для ВИМИС.
Каждое состояние пациента необходимо передавать в отдельном ресурсе. Состояние рост, вес определяется по значению параметра code.
Содержание ресурса Observation определяется по значению параметров system и code.
Список основных используемых параметров, передаваемых по справочнику
1.2.643.2.69.1.1.1.37, и их описание приведены в таблице ниже.


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 identifier Identifier 0..1 Идентификатор (номер плода при многоплодной беременности – указывается для
Observation, описывающих харакретистики конкретного плода для ВИМИС АКИНЕО)
 2.1 identifier.system uri 1..1   Пространство имён идентификатора — указывается OID передающей системы
2.2 identifier.value string 1..1 Номер плода
3 code CodeableConcept 1..1 Указание типа Observation.
Вложенные параметры:
1. coding.system — OID справочника в сервисе Терминологии,
2. coding.version — версия справочника в сервисе Терминологии,
3. coding.code — код значения из
справочника
Основной используемый справочник —
1.2.643.2.69.1.1.1.37, для передачи
дополнительных параметров заявки ВИМИС может также использоваться справочник
1.2.643.2.69.1.1.1.127
4 status code 1..1 Статус ресурса (справочник FHIR. OID
справочника в сервисе Терминологии:2.16.840.1.113883.4.642.3.400).
Всегда передается статус final.
5 valueQuantity или
valueString
Quantity
или String
1..1 Основные параметры:
Количественные показатели передаются как valueQuantity. Вложенные параметры: value — значение, code – код единицы измерения по справочнику 1.2.643.5.1.13.13.11.1358. Оба параметра обязательны.
Текстовые значения передаются как valueString Дополнительные параметры ВИМИС: могут передаваться показатели следующих типов:
valueString, valueQuantity,
valueCodeableConcept, valueDateTime,
valueBoolean 
Тип valueCodeableConcept должен содержать вложенные параметры: в параметре system указывается OID справочника в сервисе Терминологии, version — указываетсяОсновные
параметры:
Количественные показатели передаются как valueQuantity. Вложенные параметры: value — значение, code – код единицы измерения по справочнику 1.2.643.5.1.13.13.11.1358. Оба
параметра обязательны.
Текстовые значения передаются как valueString Дополнительные параметры ВИМИС: могут передаваться показатели следующих типов:
valueString, valueQuantity,
valueCodeableConcept, valueDateTime,
valueBoolean
Тип valueCodeableConcept должен содержать вложенные параметры: в параметре system указывается OID справочника в сервисе
Терминологии, version — указывается версия справочника, code — указывается код значения из справочника. Все параметры обязательные. версия справочника, code — указывается код значения из справочника. Все параметры
обязательные.

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

Condition

Ресурс Condition предназначен для передачи информации о диагнозах пациента. В этом ресурсе указывается диагноз (основной диагноз, сопутствующее заболевание, осложнение).
Содержание ресурса Condition определяется по значению параметра category. Для диагноза category == diagnosis.

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 verificationStatus CodeableConcept 1..1 Статус ресурса (справочник FHIR. OID справочника в сервисе Терминологии: 2.16.840.1.113883.4.642.1.1075).
Вложенные параметры:
1. system — OID справочника в сервисе Терминологии (2.16.840.1.113883.4.642.1.1075),
2. version — версия справочника в сервисе Терминологии,
3. code — код значения из справочника. Возможные значения:
a. provisional — для предварительных данных,
b. confirmed — для окончательных (подтвержденных).
3 category CodeableConcept 1..1 Тип Condition.
Вложенные параметры:
1. system — OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.36),
2. version — версия справочника в сервисе Терминологии,
3. code — код значения из справочника (всегда передается diagnosis).
4 code CodeableConcept 1..1 Диагноз направления. Вложенные параметры:
1. system — OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.2 или 1.2.643.5.1.13.13.11.1005 – в зависимости от региональных настроек),
2. version — версия справочника в сервисе Терминологии,
3. code — код значения согласно МКБ-10
4. display – клиническая формулировка диагноза (параметр не обязательный)
5 extension CodeableConcept 0..1

Код вида нозологической единицы диагноза (указывается, если передается не основной диагноз).
Вложенные параметры:

1. url — OID расширения (http://api.n3med.ru/api/fhir/n3extension-nosologicalunitsofdiagnosis)
2. valueCodeableConcept.system — OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1077),
3. valueCodeableConcept.version — версия справочника в сервисе Терминологии,
4. valueCodeableConcept.code — код значения из справочника
5. valueCodeableConcept.display — текстовое представление значения

6 clinicalStatus CodeableConcept 0..1

Характер заболевания. Вложенные параметры:
1. system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1049),
2. version — версия справочника в сервисе Терминологии,
3. code — код значения согласно справочнику
4. display – текстовое представление значения

7 subject reference
(Patient)
1..1

Ссылка. Соотнесение с пациентом. Должен передаваться ресурс Patient в Bundle или указывается ссылка на существующий Patient

8 recordedDate dateTime 0..1

Для диагноза указывается дата установления диагноза

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

Передача результата по заявке производится с помощью передачи в сервис ресурса Bundle.
Ресурс Bundle является контейнером, содержащий в себе набор ресурсов характерных для передаваемых данных. Для передачи Bundle необходимо отправить запрос: POST [hostname]?_format=json, в body передать ресурс Bundle. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ОДИИ.
Уникальность результата проверяется по совокупности параметров ресурса Task
identifier.system (OID передающей системы), identifier.value (идентификатор заявки в МИС), owner (передающая организация). Многократная передача одного и того же результата (с одним и тем же набором ключевых параметров) запрещена (допускается после отмены результата).

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


п/п
Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 type code 1..1 Тип Bundle
Всегда передается transaction
3 entry BackboneElement 1..* Содержание Bundle. Содержит массив передаваемых ресурсов
3.1 entry.fullUrl uri 1..1 URI ресурса (UUID). Используется для связи ресурсов внутри Bundle
3.2 entry.resource Recourse 1..1 Ресурс. Содержит параметры передаваемого ресурса
3.3 entry.request BackboneE
lement
1..1 Вложенные параметры: method — HTTP действие. Всегда передается POST

Для передачи результата должен использоваться Bundle типа транзакция. В Bundle должна
передаваться следующая информация:
● Ответ на заявку
● Общие сведения о результате (идентификатор, дата и т.п.).
● Информация о враче, выполнившем исследование и утвердившем результат.
● Информация о квалификации враче.
● Информация об устройстве, на котором выполнено исследование.
● Значение результата.
● Печатная форма протокола исследования в формате PDF.

Структура Bundle результата


п/п
Ресурс Ссылки на другие ресурсы Описание
1 Task ● Task.basedOn – ссылка на Task с Task.intent == original-order,
● Task.owner – ссылка на Organization,
● Task.focus – ссылка на DiagnosticReport
В ресурсе указывается общая информация о результате:
● идентификатор заказа в РИС и дата результата,
● ссылка на заявку,
● ссылка на результат по виду исследования (DiagnosticReport),
● Ссылка на организацию, подразделение, передающее результат, в формате Organization/GUID, где GUID – идентификатор организации, подразделения по справочнику 1.2.643.2.69.1.1.1.64 (РИС)
2 DiagnosticReport ● DiagnosticReport.subject – ссылка на Patient,
● DiagnosticReport.performer– ссылка на PractitionerRole,
● DiagnosticReport.basedOn – ссылка на ServiceRequest,
● DiagnosticReport.result – ссылка на Observation,
● DiagnosticReport.imagingStudy — ссылка на ImagingStudy
● DiagnosticReport.presentedForm.url – ссылка на Binary
В ресурсе указывается следующая информация:
● заключение по исследованию,
● ссылка на назначение,
● ссылка на квалификацию врача, утвердившего результат,
● ссылка на пациента,
● ссылка на результат,
● ссылка на протокол (PDF-документ)
3 ImagingStudy ● ImagingStudy.subject — ссылка на Patient
● ImagingStudy.interpreter — ссылка на PractitionerRole
● ImagingStudy.series.perfomer.actor
● ImagingStudy.endpoint — доступ к изображению
В ресурсе указывается информация об исследовании:
● Уникальный идентификатор исследования для формирования ссылки на просмотр в webViewer
● Описание исследования
● Ссылка на пациента
● Ссылка на квалификацию врача
● Ссылка на устройство
● Ссылка на точку доступа
4 Observation ● Observation.performer – ссылка на PractitionerRole
● Observation.related.target – ссылка на ресурс Observation
В ресурсе указывается следующая информация:
● результат,
● ссылка на квалификацию врача, выполнившего исследование
5 Device ● Device.owner – ссылка на Organization В ресурсе указывается информация о приборе исследования, которое использовалось для генерации наблюдения.
6 Practitioner ● managingOrganisation – ссылка на Organization В ресурсе указывается информация о враче: для передачи данных о врачах, выполнивших исследование и утвердивших результат.
7 Binary   В ресурсе передается протокол исследования (PDF/XML/doc/docx) и (при необходимости) открепленная УКЭП для документа
8 Endpoint   В ресурсе передаются данные для доступа к изображению

Обязательность ресурсов Bundle результата 

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

№ п/п Ресурс Кратность Операции Возможность использования ссылки на ресурс
1 Task 1..1 Создание Ресурс должен всегда передаваться в составе Bundle.
2 DiagnosticReport 1..1 Создание Ресурс должен всегда передаваться в составе Bundle.
3 ImagingStudy 0..1 усл.* Создание Ресурс должен всегда передаваться в составе Bundle.
4 Observation 0..1 усл.* Создание Ресурс должен всегда передаваться в составе Bundle.
5 Binary 0..1 усл.* Создание Ресурс должен всегда передаваться в составе Bundle.
6 PractitionerRole 0..* ● Создание
● Обновление
Ресурс может передаваться в составе Bundle.
Если ресурс не передается, то в параметрах указывается ссылка на уже существующий в БД ресурс
7 Practitioner 0..* ● Создание
● Обновление
Ресурс может передаваться в составе Bundle.
Если ресурс не передается, то в параметрах указывается ссылка на уже существующий в БД ресурс
8 Device 0..1 ● Создание
● Обновление
Ресурс может передаваться в составе Bundle.
Если ресурс не передается, то в параметрах указывается ссылка на уже существующий в БД ресурс
9 Endpoint 0..1  Создание Ресурс может передаваться в составе Bundle.
Если ресурс не передается, то в параметрах указывается ссылка на уже существующий в БД ресурс

* В общем случае результат может быть передан тремя способами:
— только информация об изображении (передается ресурс ImagingStudy со ссылкой на вьюер, передается в ресурсе Endpoint)
— только описание (передаются обязательно два ресурса Observation – отдельно описание и заключение, и как минимум один ресурс Binary с протоколом PDF), — информация об изображении и описание.
— если передается описание, то должны быть переданы как минимум два Observation с разными code — описание (code == 1) и заключение (code == 2). Если передается Observatioin — Binary с протоколом (PDF и/или CDA) обязательны к передаче

Вариант передачи Ситуация Обязательные к передаче в бандле ресурсы
Только информация об изображении Информация об изображении получена с оборудования, но описания пока нет Данные по изображению (ImagingStudy 1..1)
Только описание Информации об изображении нет и не будет, но есть описание Описание, заключение (Observation 2..2), протокол PDF (Binary без УКЭП 1..1, Binary с УКЭП 3..3, также может быть дополнительно передан CDA документ с подписями)
Информация об изображении и описание Есть и информация по изображению, и описание Данные по изображению (ImagingStudy 1..1), описание, заключение (Observation 2..2), протокол PDF (Binary без УКЭП 1..1, Binary с УКЭП 3..3, также может быть дополнительно передан CDA документ с подписями)
Второе мнение Изображение ранее описано Описание, заключение (Observation 2..2), протокол PDF (Binary без УКЭП 1..1, Binary с УКЭП 3..3, также может быть дополнительно передан CDA документ с подписями)

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

Task результата

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

№ п/п Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 identifier Identifier 1..1 Идентификатор исследования в РИС.
2.1 identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы10 (UK)
2.2 identifier.value code 1..1 Идентификатор исследования в РИС (UK)
3 basedOn Reference (Task) 1..1 Ссылка. Соотнесение с заявкой. Должна указываться ссылка на существующий в БД Task с Task.intent == original-order или Task.intent == filler-order.
4 status code 1..1

Статус (справочник FHIR. OID справочника в сервисе Терминологии: 2.16.840.1.113883.4.642.1.791)

Необходимо передавать результаты со статусом in-progress/completed
in-progress — в ходе выполнения, передается частичный результат
completed — завершено, передается окончательный результат

5 intent code 1..1

Назначение (справочник FHIR. OID справочника в сервисе Терминологии: 2.16.840.1.113883.4.642.1.114). Для Bundle результата всегда передается reflex-order (UK)

6 focus Reference (DiagnosticReport) 1..1

Ссылка. Соотнесение с результатом по виду исследования. Должен передаваться ресурс DiagnosticReport.

7 authoredOn dateTime 1..1

Ссылка. Соотнесение с результатом по виду исследования. Должен передаваться ресурс DiagnosticReport.

8 for Reference (Patient) 1..1

Ссылка. Соотнесение с пациентом. Передается ресурс Patient в Bundle или указывается ссылка на существующий Patient.

9 requester Reference (Organization) 1..1

Ссылка. Соотнесение с направляющей МО. Передается ссылка на существующий Organization11.

10 owner   1..1

Ссылка. Соотнесение с РИС. Должна указываться ссылка на существующую в БД Organization12 (UK)

      0..1

Комментарий к результату.

DiagnosticReport

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

 

№ п/п Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 meta.security code 1..1 Метаданные ресурса с данными об уровне
доступа к результату исследования.
В параметре code указывается код уровня доступа из справочника (справочник FHIR. OID
справочника в сервисе Терминологии:
1.2.643.5.1.13.13.11.1116
N – обычный,
R — ограниченный,
V — крайне ограниченный)
3 basedOn Reference
(ServiceRequest)
1..1 Ссылка. Соотнесение с назначением
(ServiceRequest). Должна указываться ссылка на существующий в БД ServiceRequest для соответствующей заявки Task.basedOn.
4 status code 1..1 Статус результата (Справочник FHIR. OID
справочника в сервисе Терминологии: 2.16.840.1.113883.4.642.1.236).
Параметр должен быть равен одному из
значений: partial/final/appended partial — передается частичный ответ (должен
соответствовать Task.status == in-progress)
final — передаются окончательный ответ
(должен соответствовать Task.status ==
completed) appended — второе мнение (должен соответствовать Task.status == completed) 
5 category CodeableConcept 1..1 Тип инструментального исследования.
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1472),
2. coding.version — версия справочника в
сервисе Терминологии,
3. coding.code — код значения из справочника
6 code CodeableConcept 1..1 Код проведенного вида исследования/услуги.
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1471),
2. coding.version — версия справочника в
сервисе Терминологии,
3. coding.code — код значения из справочника
7 subject Reference
(Patient)
1..1 Ссылка. Соотнесение с пациентом. Должна указываться ссылка на существующий в БД Patient
При передаче результата по заявке ссылка на пациента в результате и ссылка на пациента в заявке должны быть одинаковые.
8 effectiveDateTime instant 1..1 Клинически значимое время результата: датавремя проведения исследования.
9 issued instant 1..1 Дата-время утверждения результата по
исследованию.
10 performer Reference
(PractitionerRole)
1..1 Ссылка. Соотнесение с квалификацией врача, утвердившим результат. Должен передаваться ресурс PractitionerRole в Bundle или указывается ссылка на существующий PractitionerRole.
11 result Reference
(Observation)
0..5 Ссылка на результат
11 imagingStudy Reference(Im
agingStudy)
0..1 Ссылка на исследование DICOM
12 conclusionCode CodeableConcept 0..* Заключение могут передаваться: диагноз пациента, код патологии, Категория BI-RADS, Оценка ответа солидных опухолей на терапию (RECIST 1.1)
Вложенные параметры:
1. system — OID справочника в сервисе
Терминологии (1.2.643.2.69.1.1.1.2 или
1.2.643.5.1.13.13.11.1005 для кода диагноза (в зависимости от региональных настроек),
1.2.643.5.1.13.13.11.1473 для кода
патологии, 1.2.643.5.1.13.13.99.2.348 для
Категории BI-RADS,
1.2.643.5.1.13.13.99.2.572 для Оценки ответа солидных опухолей на терапию,
2. version — версия справочника в сервисе Терминологии,
3. code — код значения
13 presentedForm Attachment 0..* Ссылка на ресурс Binary (соотнесение с PDF и/или XML документом и УКЭП к ним).
Передаются ссылки на PDF и/или XML документ, УКЭП врача и УКЭП МО к ним.
1. При передаче протокола результата без УКЭП передается один ресурс Binary с данными протокола, при этом параметр
DiagnosticReport.presentedForm содержит
ссылку на единственный в Bundle ресурс
Binary.
2. При передаче протокола (PDF и/или XML) с УКЭП передается по три ресурса Binary: сам протокол, УКЭП МО, УКЭП врача, при этом параметр DiagnosticReport.presentedForm
содержит соответствующее количество
ссылок на ресурсы Binary. 
13.1 presentedFor
m.contentType
code 1..1 Тип содержимого в ресурсе.
Параметр DiagnosticReport.presentedForm.contentType
должен соответствовать параметру
Binary.contentType для ресурса Binary,
указанного в параметре
DiagnosticReport.presentedForm.url.
13.2 presentedForm.ur uri 1..1 Ссылка на ресурс Binary. Соотнесение с
документом. Указывается при передаче Binary

ImagingStudy

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

№ п/п Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 identifier Identifier 2..2 Передается два идентификатора
исследования:
1. Accession number
2. Study Instance UID (0020,000D)
2.1 identifier.type CodeableConcept 1..1
усл

Тип идентификатора
Вложенные параметры:
1. coding.system — OID справочника в
сервисе Терминологии
(1.2.643.2.69.1.1.1.122),
2. coding.version — версия справочника в
сервисе Терминологии,
3. coding.code — всегда передается
значение ACSN

усл.: передается только для
идентификатора accession number

2.2 identifier.system uri 1..1 Пространство имен идентификатора:
1. Для передачи accession number в
качестве кодовой системы указывается
OID передающей системы.
2. Для передачи Study Instance UID всегда
передавать urn:dicom:uid
2.3 identifier.value string 1..1

Идентификатор
1. Идентификатор accession number
(должен совпадать с идентификатором
заявки в сервисе Task.identifier при
Task.identifier.type == ACSN)

2. Идентификатор Study Instance UID
всегда передавать с префиксом
“urn:oid:”

3 status code 1..1 Статус результата (Справочник FHIR. OID
справочника в сервисе Терминологии:
2.16.840.1.113883.4.642.1.991).
Передавать значение available
4 subject Reference(Patient) 1..1 Ссылка на пациента
5 interpreter Reference(Practiti
onerRole)
0..1 Ссылка на квалификацию врача
6 endpoint Reference(Endpoi
nt)
0..1 Доступ к исследованию (ссылка на viewer, Endpoint.connectionType = ihe-iid)
7 description Reference 0..1 Доступ к исследованию (готовая ссылка на исследование для вызова вьюера)
8 series BackboneElement 0..* Данные серии изображений
8.1 series.uid id 1..1 DICOM Series Instance UID
8.2 series.perfomer BackboneElement 1..1 Исполнитель исследования
8.2.1 series.perfomer.actor Reference(Device) 1..1 Ссылка на устройство, на котором
выполнялось исследование.
8.3 series.instance BackboneElement 1..* Данные изображения
8.3.1 series.instance.uid id 1..1 DICOM SOP Instance UID
8.3.2 series.instance
.sopClass
Coding 1..1 DICOM class type
Вложенные параметры:
1. system — OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.125),
2. version — версия справочника в
сервисе Терминологии,
3. code — значение из справочника.

PractitionerRole

Ресурс PractitionerRole предназначен для передачи информации о квалификации врача. В
этом ресурсе указывается:
● Специальность
● Должность
● Место работы
● Врач
Параметры ресурса PractitionerRole приведены в разделе передачи данных врача.

Practitioner

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

Observation результата

В Bundle для передачи результата ресурс Observation предназначен для передачи
результата исследования (в Bundle для передачи заявки этот же ресурс используется для указания других параметров) и для передачи дополнительной информации по результату для формирования СМС ВИМИС.
Содержание ресурса Observation определяется по значению параметров system и code
Содержание ресурса Observation определяется по значению параметра code (согласно
справочнику 1.2.643.2.69.1.1.1.119). По параметру code определяется заполнения полей
valueString.

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

Значение
code.coding.code
Назначение Тип данных
1 Описание инструментального исследования valueString
2 Заключение инструментального исследования valueString
3 Рекомендации по результатам лабораторного
исследования
valueString
4 Примененный при использовании контраст valuecodeableConcept
5 Лучевая нагрузка, мЗв valueQuantity

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

№ п/п Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 identifier Identifier 0..1 Идентификатор (номер плода при
многоплодной беременности – указывается
для Observation, описывающих харакретистики конкретного плода для ВИМИС АКИНЕО)
2.1 identifier.system uri 1..1 Пространство имён идентификатора —
указывается OID передающей системы
2.2 identifier.value string 1..1 Номер плода
3 status code 1..1 Статус ресурса (справочник FHIR. OID
справочника в сервисе
Терминологии:2.16.840.1.113883.4.642.3.400).
При передачи окончательного результата
необходимо передавать статус final.
4 code CodeableConcept 1..1 Указание типа Observation:
— system — OID справочника в сервисе
Терминологии,
— version — версия справочника в сервисе
Терминологии,
— code — код значения из справочника
Основной используемый справочник —
1.2.643.2.69.1.1.1.119, для передачи
дополнительных параметров результата
ВИМИС может также использоваться
справочник 1.2.643.2.69.1.1.1.127
5 issued instant 1..1 Дата-время выполнения исследования
6 performer Reference
(PractitionerRole)
1..1 Ссылка. Соотнесение с квалификацией врача, описывающего протокол исследования.
Должен передаваться ресурс PractitionerRole в Bundle или указываться ссылка на
существующий PractitionerRole
7 valueString string 1..1 усл. * Текстовый результат. Содержит описание,
заключение, рекомендации или дополнительные данные результата (в
зависимости от значения параметра code).
8 valuecodeableConcept codeableConcept 1..1 усл. * Примененный при использовании контраст.
Вложенные параметры:
1. system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.99.2.540),
2. version — версия справочника в сервисе
Терминологии,
3. code — код значения из справочника
9 valueQuantity Quantity 1..1 усл. * Лучевая нагрузка в Миллизивертах.
Вложенные параметры:
1. value — объем лучевой нагрузки,
2. code — код е.и. из справочника
1.2.643.5.1.13.13.11.1358
10 interpretation CodeableConcept 0..1 Интерпретация результата исследования
Вложенные параметры:
1. system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1381),
2. version — версия справочника в сервисе
Терминологии,
3. code — код значения из справочника (530)
11 device Reference(Device) 0..1 Ссылка на устройство, на котором
выполнялось исследование.
Обязательно для ВИМИС
12 note string 0..1 Комментарий к результату исследования

* Должен передаваться один из параметров – valueString, valueQuantity или valuecodeableConcept

Device

Для передачи данных об устройстве в Bundle необходимо использовать ресурс Device.
Параметры ресурса Device приведены в разделе передачи данных устройства.

Endpoint

Для передачи данных о PACS-сервере (месте хранения изображения) в Bundle необходимо использовать ресурс Endpoint.
Параметры ресурса Endpoint приведены в разделе передачи данных устройства

Binary

В Bundle для передачи протокола исследования и УКЭП используется ресурс Binary.
В качестве документа должен передаваться пригодный для просмотра и печати протокол исследования в формате PDF, соответствующий передаваемым результатам. Передача пустого документа или документа, не содержащего требуемых данных, не допускается. Вставка текста в документ в виде изображения не допускается.
Файл PDF документа в электронном виде должен иметь формат PDF/A-1,
соответствующий международному стандарту ISO 19005-1:2005 «Управление документацией.
Формат файлов электронных документов для долгосрочного сохранения. Часть 1: Использование формата PDF 1.4 (PDF/A-1)» — Document management — Electronic document file format for long-term preservation — Part 1: Use of PDF 1.4 (PDF/A-1) [5].
Дополнительно может передаваться XML-документ, пригодный для передачи в РЭМД CDA, соответствующий передаваемым структурированным данным и требованиям, размещенным на портале ЕГИСЗ, в форматах, разрешенных справочником
https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.11.1520 . Версии (редакции) CDA документов, передаваемых в сервис, определяются органом управления здравоохранением. Тип и версия передаваемого в РЭМД документа должны быть указаны в параметре Binary.meta.tag
Для выгрузки в федеральные сервисы PDF и XML документы должны быть подписаны. В качестве подписи должна передаваться УКЭП в формате CMS (Cryptographic Message Syntax).
УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012. Детальные требования к УКЭП размещены на портале ЕГИСЗ

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

№ п/п Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 meta.tag code 0..1 Метаданные ресурса с данными о версии
документа, выгружаемого в РЭМД, по
справочнику 1.2.643.5.1.13.13.11.1520.
Указывается только для Binary, в которых
передается PDF или CDA документ. Для
подписей параметр не передается.
Вложенные параметры:
1. system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1520),
2. version — версия справочника в сервисе
Терминологии,
3. code — код значения из справочника.
3 ContentType code 1..1 Тип содержимого в ресурсе, передается всегда:
— contentType = application/pdf для протокола в
формате PDF, application/x-pkcs7-practitioner
для УКЭП врача и application/x-pkcs7-
organization для УКЭП МО для бланка рецепта
в формате PDF
Расширенный перечень ресурсов,
необязательных к передаче, приведен в
таблице ниже. Возможность и обязательность передачи расширенного перечня включается в настройках сервиса
4 data Base64Binary 1..1 Файл PDF, XML или УКЭП в формате
base64binary

Типы Binary


п/п
Contenttype Получатель
документа
Подпись врача Подпись МО
1 application/pdf РЭМД application/x-pkcs7-
practitioner
application/x-pkcs7-
organization
2 application/xml РЭМД, ФИЭМК application/x-pkcs7-
practitioner-xml
application/x-pkcs7-
organization-xml
3 application/xakineo ВИМИС АкиНео application/x-pkcs7-
practitioner-akineo*
application/x-pkcs7-
organization-akineo*
4 application/x-onko ВИМИС Онко application/x-pkcs7-
practitioner-onko*
application/x-pkcs7-
organization-onko*
5 application/x-prof ВИМИС Проф application/x-pkcs7-
practitioner-prof*
application/x-pkcs7-
organization-prof*
6 application/x-ssz ВИМИС ССЗ application/x-pkcs7-
practitioner-ssz*
application/x-pkcs7-
organization-ssz*

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

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

● Общие сведения о результате (отправитель, получатель,идентификатор, дата и
т.п.).
● Информация о пациенте.
● Информация о враче, выполнившем исследование и утвердившем результат.
● Значение результата.
Отличие от аналогичного Bundle результата следующие:
● В Bundle включен ресурс Patient;
● В ресурс Task добавлен параметр направляющей организации;
● В Bundle Не передаются параметры Task.basedOn, DiagnosticReport.basedOn.

Уникальность результата проверяется по совокупности параметров ресурса Task
identifier.system (OID передающей системы), identifier.value (идентификатор заявки в МИС), owner (передающая организация). Многократная передача одного и того же результата (с одним и тем же набором ключевых параметров) запрещена (допускается после отмены результата).

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

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


п/п
Ресурс Ссылки на другие ресурсы Описание
1 Task    
2 DiagnosticReport    
3 ImagingStudy

 

 

См.описание ресурсов, входящих в состав Bundle результата

4 Observation
5 PractitionerRole
6 Practitioner
7 Device
8 Binary
9 Endpoint
1`0 Patient

 

См.описание резурсов, входящих в состав Bundle заявки

11 Encounter
12 Condition

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

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


п/п
Ресурс Кратность Операции Возможность использования
ссылки на ресурс
1 Task 1..1 Создание Ресурс должен всегда
передаваться в составе Bundle
2 DiagnosticReport 1..1 Создание Ресурс должен всегда
передаваться в составе Bundle
3 ImagingStudy 0..1 Создание Ресурс должен всегда
передаваться в составе Bundle
4 Observation 0..2 усл.* Создание Ресурс должен всегда
передаваться в составе Bundle
5 PractitionerRole 0..* ● Создание
● Обновление
Ресурс может передаваться в
составе Bundle.
Если ресурс не передается, то в
параметрах указывается ссылка
на уже существующий в БД ресурс
6 Practitioner 0..* ● Создание
● Обновление
Ресурс может передаваться в
составе Bundle.
Если ресурс не передается, то в
параметрах указывается ссылка
на уже существующий в БД ресурс
7 Patient 0..1 ● Создание
● Обновление
Ресурс может передаваться в
составе Bundle.
Если ресурс не передается, то в
параметрах указывается ссылка
на уже существующий в БД ресурс
8 Device ..* ● Создание
● Обновление
Ресурс может передаваться в
составе Bundle.
Если ресурс не передается, то в
параметрах указывается ссылка
на уже существующий в БД ресурс
9 Binary 0..3 усл* Создание Ресурс должен всегда
передаваться в составе Bundle
10 Endpoint 0..1 Создание Ресурс может передаваться в
составе Bundle.
Если ресурс не передается, то в
параметрах указывается ссылка
на уже существующий в БД ресурс
11 Encounter 0..1 Создание Ресурс может передаваться в
составе Bundle.
Если ресурс не передается, то в
параметрах указывается ссылка
на уже существующий в БД ресурс
12 Condition 0..1 Создание Ресурс может передаваться в
составе Bundle.
Если ресурс не передается, то в
параметрах указывается ссылка
на уже существующий в БД ресурс

* В общем случае результат может быть передан тремя способами:
— только информация об изображении (передается ресурс ImagingStudy со ссылкой на
вьюер, передается в ресурсе Endpoint)
— только описание (передаются обязательно два ресурса Observation – отдельно описание и заключение, и один ресурс Binary с протоколом PDF),
— информация об изображении и описание. Правила формирования и требования к передаче отражены в таблице ниже.

Вариант передачи Ситуация Обязательные к передаче в
бандле ресурсы
Только информация
об изображении
Информация об изображении получена с оборудования, но описания пока нет Данные по изображению
(ImagingStudy 1..1)
Только описание Информации об изображении нет и не будет, но есть описание Описание, заключение
(Observation 2..2), протокол PDF
(Binary без УКЭП 1..1, Binary с
УКЭП 3..3 )
Информация об изображении и описание Есть и информация по изображению, и описание Данные по изображению
(ImagingStudy 1..1), описание,
заключение (Observation 2..2),
протокол PDF (Binary без УКЭП
1..1, Binary с УКЭП 3..3 )
Второе мнение Изображение ранее описано Описание, заключение
(Observation 2..2), протокол PDF
(Binary без УКЭП 1..1, Binary с
УКЭП 3..3 )

Если передается Observation, то можно передавать только два Observation с разными code
— описание (code == 1) и заключение (code == 2). Любые другие варианты не допускаются. Если передается Observatioin — Binary обязательны к передаче
Можно передавать или один Binary с «contentType» : «application/pdf», или три Binary с
«contentType» : «application/pdf», «contentType» : «application/x-pkcs7-practitioner», «contentType» : «application/x-pkcs7-organization». Любые другие варианты не допускаются. Если передается Binary 
— Observatioin обязательны к передаче

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

Task результата без заявки

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

№ п/п Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 identifier Identifier 1..1 Идентификатор исследования в РИС.
2.1 identifier.system uri 1..1 В качестве кодовой системы указывается
OID передающей системы (UK)
2.2 identifier.value code 1..1 Идентификатор исследования в РИС (UK)
3 basedOn Reference
(Task)
0..0 Не передается для Bundle результата без
заявки
4 status code 1..1 Статус (справочник FHIR. OID справочника в
сервисе Терминологии:
2.16.840.1.113883.4.642.1.791)
Необходимо передавать результаты со
статусом completed (завершено, передается
окончательный результат
5 intent code 1..1 Назначение (справочник FHIR. OID
справочника в сервисе Терминологии:
2.16.840.1.113883.4.642.1.114). Для Bundle
результата всегда передается reflex-order
(UK)
6 focus Reference
(DiagnosticReport)
1..1 Ссылка. Соотнесение с результатом по виду
исследования. Должен передаваться ресурс
DiagnosticReport.
7 authoredOn dateTime 1..1 Дата-время утверждения результата (yyyyMM-ddTHH:mm:sszzz).
8 for Reference
(Patient)
1..1 Ссылка. Соотнесение с пациентом.
Передается ресурс Patient в Bundle или
указывается ссылка на существующий
Patient.
9 requester Reference
(Organization)
1..1 Ссылка. Соотнесение с направляющей МО.
Передается ссылка на существующий
Organization
10 owner Reference
(Organization)
1..1 Ссылка. Соотнесение с РИС. Должна
указываться ссылка на существующую в БД
Organization (UK)
11 note Annotation 0..1 Комментарий к результату.

DiagnosticReport результата без заявки

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

№ п/п Параметр Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
2 meta.security
.code
code 1..1 Метаданные ресурса с данными об уровне
доступа к результату исследования.
В параметре code указывается код уровня
доступа из справочника (справочник FHIR. OID справочника в сервисе Терминологии:
1.2.643.5.1.13.13.11.1116
N – обычный,
R — ограниченный,
V — крайне ограниченный)
3 basedOn Reference
(ServiceRequest)
0..0 Не передается для Bundle результата без
заявки.
4 status code 1..1 Статус результата (Справочник FHIR. OID
справочника в сервисе Терминологии:
2.16.840.1.113883.4.642.1.236).
Параметр должен быть равен одному из
значений: partial/final
partial — передается частичный ответ (должен соответствовать Task.status == in-progress)
final — передаются окончательный ответ
(должен соответствовать Task.status ==
completed)
appended — второе мнение (должен
соответствовать Task.status == completed)
5 category CodeableConcept 1..1

Тип инструментального исследования.
Вложенные параметры:
1. coding.system — OID справочника в сервисе
Терминологии (1.2.643.5.1.13.13.11.1472),
2. coding.version — версия справочника в
сервисе Терминологии,

3. coding.code — код значения из справочника

6 encounter Reference
(Encounter)
0..1

Ссылка. Соотнесение со случаем обслуживания.
Должен передаваться ресурс Encounter в Bundle

7 effectiveDateTime instant 1..1

Клинически значимое время результата: датавремя проведения исследования.

8 issued instant 1..1

Дата-время утверждения результата по
исследованию.

9 performer Reference
(PractitionerRole)
1..1

Ссылка. Соотнесение с квалификацией врача, утвердившим результат. Должен передаваться ресурс PractitionerRole в Bundle или указывается ссылка на существующий PractitionerRole.

10 result Reference
(Observation)
0..5

Ссылка на результат

11 imagingStudy Reference(Im
agingStudy)
0..1

Ссылка на исследование DICOM

12 conclusionCode CodeableConcept 0..*

Заключение: диагноз пациента.
Вложенные параметры:
1. system — OID справочника в сервисе
Терминологии (1.2.643.2.69.1.1.1.2 или
1.2.643.5.1.13.13.11.1005 – в зависимости от
региональных настроек),
2. version — версия справочника в сервисе
Терминологии,
3. code — код значения согласно МКБ-10.

13 presentedForm Attachment 0..6

Ссылка на ресурс Binary (соотнесение с PDF
и/или XML документом и УКЭП к ним).
Передаются ссылки на PDF и/или XML документ, УКЭП врача и УКЭП МО к ним.
3. При передаче протокола результата без
УКЭП передается один ресурс Binary с
данными протокола, при этом параметр
DiagnosticReport.presentedForm содержит
ссылку на единственный в Bundle ресурс
Binary.
1. При передаче протокола (PDF и/или XML) с УКЭП передается по три ресурса Binary: сам протокол, УКЭП МО, УКЭП врача, при этом параметр DiagnosticReport.presentedForm содержит три или шесть ссылок на ресурсы Binary.

13.1 presentedFor
m.contentTy
pe
code 1..1

Тип содержимого в ресурсе.
Параметр DiagnosticReport.presentedForm.contentType
должен соответствовать параметру
Binary.contentType для ресурса Binary,
указанного в параметре
DiagnosticReport.presentedForm.url.

13.2 presentedForm.url uri 1..1

Ссылка на ресурс Binary

ImagingStudy

Параметры ресурса ImagingStudy совпадают с параметрами ресурса ImagingStudy в Bundle результата и приведены в разделе передачи данных исследования.

PractitionalRole

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

Practitioner

Параметры ресурса Practitioner совпадают с параметрами ресурса Practitioner в Bundle результата и приведены в разделе передачи данных врача.

Patient

Параметры ресурса Patient совпадают с параметрами ресурса Patient в Bundle заявки и приведены в разделе передачи данных пациента.

Encounter

Параметры ресурса Encounter совпадают с параметрами ресурса Encounter в Bundle заявки и приведены в разделе передачи заявки.

Condition

Параметры ресурса Condition совпадают с параметрами ресурса Condition в Bundle заявки и приведены в разделе передачи заявки.

Observation результата

Параметры ресурса Observation совпадают с параметрами ресурса Observation в Bundle результата и приведены в разделе передачи данных результатов.

Device

Параметры ресурса Device совпадают с параметрами ресурса Device в Bundle результата и приведены в разделе передачи данных устройства

Endpoint

Параметры ресурса Endpoint совпадают с параметрами ресурса Endpoint в Bundle результата и приведены в разделе передачи данных места хранения.

Binary

Параметры ресурса Binary совпадают с параметрами ресурса Binary в Bundle результата и приведены в разделе передачи данных протокола.

Передача результата частями. Референсные центры.

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

Исследование и описание делаются в рамках одной МО

В процессе участвуют две МО – направляющая и целевая (исполнитель). В данном случае рекомендуется следующая последовательность действий:

— в направляющей МО создается заявка на исследование (Task.intent == original-order)
— в целевой МО после выполнения исследования (снимки) создается результат на это
исследование, содержащая только сведения об изображении (Task.intent == reflex-order, при этом Task.status == in-progress, DiagnosticReport.status == partial – работа над данным исследованием в данной МО не завершена)
— в целевой МО после описания исследования (протокол) создается результат на это
исследование, содержащая только сведения протоколе (описание, заключение, рекомендации, документы CDA и PDF) (Task.intent == reflex-order, при этом Task.status == completed, DiagnosticReport.status == final – работа над данным исследованием в данной МО завершена)

Исследование и описание делаются в рамках разных МО

В процессе участвуют три МО – направляющая, целевая (исполнитель снимка), референсный центр (исполнитель расшифровки). В данном случае рекомендуется следующая последовательность действий:
— в направляющей МО создается заявка на исследование в целевую МО (Task.intent == originalorder)
— в целевой МО после выполнения исследования (снимки) создается результат на это
исследование, содержащая только сведения об изображении (Task.intent == reflex-order, при этом Task.status == completed, DiagnosticReport.status == final – работа над данным исследованием в данной МО завершена)
— в целевой МО для снимков, подлежащих расшифровке, создается заявка на расшифровку в референсный центр. К бандлу такой заявки применяются дополнительные требования:
— Task заявки должен передаваться с типом «intent»: «filler-order»;
— параметр Task.basedOn.reference должен быть заполнен и ссылаться на существующий Task результата, содержащий сведения об изображении;
— параметр ServiceRequest.SupportingInfo.reference должен быть заполнен и ссылаться на существующий ImagingStudy содержащий сведения об изображении;
— парметр ServiceRequest.encounter.reference может отсутствовать
— параметр ServiceRequest.coding.code кодируется по справочнику 1.2.643.5.1.13.13.11.1070
— в референсном центре после описания исследования (протокол) создается результат на это исследование, содержащая только сведения протоколе (описание, заключение, рекомендации, документы CDA и PDF) (Task.intent == reflex-order, при этом Task.status == completed, DiagnosticReport.status == final – работа над данным исследованием в референсном центре завершена)

Отмена / отклонение заявки

Сервис ОДИИ поддерживает метод отмены/отклонения заявок. Заявками считаем ресурсы Task с Task.intent == original-order.
Поддерживаемые статусы:
1. cancelled — отмена заявки направляющей МО;
2. rejected — отклонение заявки целевой МО.
Для отмены / отклонения заявки необходимо отправить запрос:
POST [hostname]/$updatestatus?_format=json, в body передать ресурс Parameters.
Отмена / отклонения заявки может производиться по следующим сценариям:
1. Отмена заявки направляющей МО:
a. Направляющая МО передала успешно в сервис заявку. Статус заявки requested.
b. В заявке обнаружены ошибки.
c. Заявку отменяет направляющая МО методом $updatestatus. Передает статус
cancelled.
d. Заявка приобретает статус cancelled
2. Отклонение заявки целевой МО после запроса ее из сервиса:a. Заявка передана в сервис. Статус заявки requested
b. Целевая МО запросила заявку из сервиса.
c. Целевая МО оценивает заявку.
d. Если заявка необоснованная Целевая МО отклоняет заявку методом $updatestatus.
Передает статус rejected.
e. Заявка приобретает статус rejected.
3. Отклонение заявки после подтверждения заявки методом POST Schedule:
a. Заявка передана в сервис. Статус заявки requested
b. Целевая МО запросила заявку из сервиса.
c. Целевая МО оценивает заявку.
d. Целевая МО подтверждает заявку методом POST Schedule.
e. Заявка приобретает статус accepted.
f. После подтверждения заявки произошли изменения (оборудование сломалось без
замены, и пр.) и целевая МО отклоняет заявку методом $updatestatus Передает
статус rejected.
g. Заявка приобретает статус rejected.
4. Отмена заявки после получения статуса аннулировано из УО:
a. Сервис ОДИИ запрашивает данные подтвержденных заявок из УО.
b. Если статус заявки в УО == 0 (аннулировано), сервис ОДИИ отклоняет заявку
c. Заявка приобретает статус rejected.

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

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


п/п
Имя параметра Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса
Parameters
2 parameter BackboneElement 2..2 Содержит перечень параметров
для поиска ресурса Task
2.1 parameter.name string 1..1 Наименование параметра поиска (см. таблицу значений
parameter.name)
2.2 parameter.valueString string 1..* Значение параметра.

Таблица значений parameter.name


п/п
parameter.name Соответствующий параметр Task Описание
1 _id Task.id Идентификатор ресурса Task в сервисе
2 status   Статус ресурса Task
rejected — отклоняет целевая МО
cancelled — отклоняет направляющая МО

Отмена результата

Сервис ОДИИ поддерживает метод отмены результата. Результатами считаем ресурсы Task с Task.intent == reflex-order.
Для отмены результата необходимо отправить запрос:
POST [hostname]/$updatestatus?_format=json, в body передать ресурс Parameters.
Отмена / отклонения заявки может производиться по следующим сценариям:

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

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


п/п
Имя параметра Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса Parameters
2 parameter BackboneElement 2..2 Содержит перечень параметров для поиска ресурса Task
2.1 parameter.name string 1..1 Наименование параметра поиска
(см. таблицу значений parameter.name)
2.2 parameter.valueString string 1..* Значение параметра.

Таблица значений parameter.name


п/п
parameter.name Соответствующий параметр Task Описание
1 _id Task.id Идентификатор ресурса Task в сервисе
2 status   Статус ресурса Task. Всегда передается cancelled

Запрос заявок / результатов (_search)

Метод _search – метод FHIR поиска ресурсов по типам и по запрашиваемым параметрам.
Данный метод позволяет получить заявки и результаты по следующим кейсам:
1. Кейс 1 (получение заявки): целевой МО необходимо получить заявки.
2. Кейс 2 (получение результата): направляющей МО необходимо получить
результаты
Для получения заявок / результатов необходимо отправить запрос:
POST [hostname]/Task/_search?_format=json, в body передать ресурс
В ответе сервис возвращает json с массивом parameter, содержащий ресурсы Task
найденных по условиям запроса в сервисе ОДИИ.
Внутри ресурсов Task имеются ссылки на другие ресурсы. Информация по ним
запрашивается с помощью функционала получения ресурса по GUID (GET с указанием ссылки на запрашиваемый ресурс), для чего запрашивающая система должна выполнить соответствующие запросы. Структура этих запросов описана в разделе «Запрос ресурсов».

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

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


п/п
Имя параметра Тип Кратность Описание
1 resourceType string 1..1 Наименование ресурса. Всегда указывается Parameters
2 parameter BackboneElement 1..* Содержит перечень параметров для поиска ресурса Task
2.1 parameter.name string 1..1 Наименование параметра поиска (см. таблицу значений parameter.name)
2.2 parameter.valueString string 1..* Значение параметра поиска. Для поиска по множеству указывать
значения через запятую.

Таблица значений parameter.name


п/п
parameter.name Соответствующий параметр Task Описание
1 intent Task.intent original-order — для поиска заявки
reflex-order — для поиска результатов
2 _id Task._id Идентификатор ресурса Task в сервисе
3 identifier Task.identifier.value Идентификатор заявки/результата. Указывается значение identifier.value.
Для заявки указывается идентификатор заявки в МИС, или идентификатор с Task.type.coding.code
== ACSN.
4 based-on Task.basedOn.reference Ссылка на заявку. Указывается при по поиске результата по заявке.
5 owner Task.owner.reference GUID организации, подразделения исп
6 requester Task.requester.reference GUID направляющей организации, подразделения по справочнику
1.2.643.2.69.1.1.1.64.
7 patient Task.for.reference Ссылка на пациента
8 status Task.status Статус ресурса Task
9 . _lastUpdated Task.meta.lastUpdated Дата обновления ресурса в сервисе
10 . authored-on Task.authored-on Дата направления / дата результата

Полное описание метода _search — https://www.hl7.org/fhir/search.html
Полное описание параметров поиска ресурса Task — http://hl7.org/fhir/task.html#search
Примеры body для некоторых условий поиска:

— поиск заявки по идентификатору (Accession number или OrderMisId)
{
«resourceType»: «Parameters»,
«parameter»: [
{
«name»: «intent»,
«valueString»: «original-order»
},
{
«name»: «identifier»,
«valueString»: «{{accessionKey}}»
}
]
}

— поиск результата по идентификатору заявки, присвоенному сервисом (Task/id)

{
«resourceType»: «Parameters»,
«parameter»: [
{
«name»: «intent»,
«valueString»: «reflex-order»
},
{
«name»: «based-on»,
«valueString»: «Task/{{TaskOrderId}}»
}
]
}

Запрос подтвержденной планируемой даты проведения исследования

Для получения подтвержденной планируемой даты проведения исследования необходимо отправить запрос: GET [hostname]/ Schedule/?identifier=[ACSN заявки]
В ответе сервис возвращает json с массивом parameter, содержащий ресурсы Schedule, найденные по условиям запроса в сервисе ОДИИ.

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

Для получения данных любого ресурса необходимо отправить запрос:
GET [hostname]/[Наименование ресурса]/[идентификатор ресурса в сервисе
ОДИИ]?_format=json.
В ответе сервис возвращает найденный ресурс

Выгрузка результатов исследований в ВИМИС

На данный момент в зависимости от региональных настроек может быть реализована одна из схем работы с ВИМИС:
1. CDA документы для передачи в ВИМИС формируются на стороне МО-исполнителя
и передаются в составе бандла результата, результата без заявки при наступлении требуемого события и в автоматическом режиме выгружаются в ВИМИС
2. CDA документы для передачи в ВИМИС формируются на стороне сервиса ОДИИ из
структурированных данных, переданных в составе бандла результата, результата без заявки при наступлении требуемого события и в автоматическом режиме выгружаются в ВИМИС

Схема №1.

МО-исполнитель самостоятельно формирует CDA документ для выгрузки в ВИМИС в
соответствии с актуальным описанием, размещенном на портале оперативного взаимодействия участников ЕГИСЗ http://portal.egisz.rosminzdrav.ru/materials и передает его в составе бандла результата, результата без заявки в ресурсе Binary
Для возможности выгрузки переданных CDA документов в ВИМИС при передаче ресурса Binary с CDA документом ВИМИС корректно заполнить параметр Binary.meta.tag (см. описание передачи ресурса Binary), при этом:
— в параметре system указывается OID справочника в сервисе Терминологии
(1.2.643.5.1.13.13.11.1520 для СЭМД или 1.2.643.5.1.13.13.99.2.592 для СЭМД бета),
— в параметре version указывается версия справочника в сервисе Терминологии,
— в параметре code указывается код значения из справочника, соответствующий
передаваемому документу
— в параметре display указывается код значения из справочника, соответствующий версии
передаваемого ВИМИС документа (docTypeVersion),
В случае, если параметр Binary.meta.tag заполнен неверно или отсутствует, передача
документа в ВИМИС невозможна.

Схема №2.

МО-исполнитель передает результат в сервис ОДИИ штатным порядком, уделяя особе
внимание заполнению всех известных полей:
— для заявки и результата без заявки – всегда должны быть заполнены дополнительные данные по диагнозу (вид нозологической единицы, характер заболевания) и дополнительные данные карты пациента (тип карты, дата выдачи, номер карты)
— для результата, результата без заявки ОДИИ – всегда должны быть переданы данные по использованному оборудованию (серийный, инвентарный номера и тип оборудования по справочнику 1.2.643.5.1.13.13.11.1071)
— для результата, подлежащего передаче в ВИМИС SMS V2 АкиНео (ультразвуковое
исследование ОДИИ) должны быть переданы дополнительные витальные параметры. Передача дополнительных витальных параметров в каждом регионе реализована по своему, правила их заполнения необходимо уточнять в МИАЦ региона.
В связи с большим количеством дополнительных параметров SMS V2 АкиНео
формирование указанного SMS из «Результата без заявки» невозможно. Для корректного формирования ВИМИС необходимо передавать заявку с дополнительными данными и результат с дополнительными данными. ВИМИС осуществляет валидацию состава входящих данных в зависимости от диагноза – правила необходимо смотреть в актуальном ПИВ ВИМИС АкиНео
Непосредственно выгрузка в федеральные сервисы (СЭМД, РЭМД) осуществляется
отдельными сервисами, не являющимися частью ОДИИ. Все вопросы по выгрузке результатов в федеральные сервисы, включая получение логов, следует адресовать в подразделение, ответственное за выгрузку.
В случае выявления ошибок передачи, связанных с неполными или некорректными
данными, переданными со стороны МО-исполнителя, разбор и исправление данных ошибок осуществляется сотрудниками, осуществляющими техническую поддержку ИС в МО.

Выгрузка результатов исследований в РЭМД

Для возможности передачи протоколов исследований в федеральный сервис РЭМД
(http://portal.egisz.rosminzdrav.ru/materials/1879) необходимо обеспечить выполнение ряда условий:
— у врача-исполнителя и пациента должен быть указан корректный СНИЛС;
— результат должен передаваться от имени структурного подразделения (ТВСП).
Результаты, переданные от имени головной МО, не выгружаются в РЭМД;
— совместно с протоколом исследования должны передаваться электронные подписи –
УКЭП врача и УКЭП МО. УКЭП должна передаваться в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012;
— протокол исследования может передаваться в форматах, разрешенных справочником https://nsi.rosminzdrav.ru/#!/refbook/1.2.643.5.1.13.13.11.1520 ;
— тип и версия передаваемого в РЭМД документа должны быть указаны в параметре
Binary.meta.tag;
— протоколы исследования и УКЭП в формате base64binary передаются в ресурсах Binary, ссылки на эти ресурсы передаются в DiagnosticReport, тип содержимого в ресурсе передается через параметр ContentType.
Детальная информация приведена в описании правил передачи ресурса Binary
При передаче документов в федеральный сервис РЭМД накладываются определенные ограничения на передаваемые данные, поэтому при включенной интеграции с РЭМД в сервисе ОДИИ включаются дополнительные проверки:
1. Проверяется наличие СНИЛС врача:

— передаваемый в бандле ресурс Practitioner должен содержать СНИЛС врача. Параметр
identifier с identifier.system = urn:oid:1.2.643.2.69.1.1.1.6.223 должен быть, identifier.value не может
быть пустым
2. Запрещается передача результатов исследований без УКЭП врача и УКЭП МО
3. Передаваемая УКЭП врача проверяется:
— на соответствие СНИЛС врача, указанного в файле УКЭП, и СНИЛС врача, указанного в DiagnosticReport.performer.reference.
— на соответствие ФИО врача, указанного в файле ЭЦП, и ФИО врача, указанного в
DiagnosticReport.performer.reference
— на соответствие передаваемому протоколу PDF.
4. Передаваемая УКЭП МО проверяется:
— на соответствие ОГРН МО, указанного в файле УКЭП, и ОГРН МО, указанный в
справочнике МО для МО, указанной в OrderResponce.who
— на соответствие передаваемому документу.
В случае невыполнения указанных условий сервис возвращает соответствующие ошибки.
Если результат принят сервисом – он считается прошедшим базовые проверки и пригодным для выгрузки в РЭМД.
Непосредственно выгрузка в федеральные сервисы (СЭМД, РЭМД) осуществляется
отдельными сервисами, не являющимися частью ОДИИ. При передаче сведений в федеральные сервисы дополнительно проверяется совпадение передаваемой организации, должности врача, СНИЛС врача на соответствие данным ФРМР, а также выполняется форматно-логический контроль. Все вопросы по выгрузке результатов в федеральные сервисы, включая получение логов, следует адресовать в подразделение, ответственное за выгрузку.

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

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

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

Получение информации о справочнике осуществляется с помощью 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. Метод возвращает метаинформацию о справочнике и пары код-значение.
Пример запроса:
POST [base]/ValueSet/$expand?_format=json
{
«resourceType»: «Parameters»,
«parameter»: [
{
«name»: «system»,
«valueString»: «urn:oid:1.2.643.2.69.1.1.1.64»
}
]
}

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

Метод предназначен для получения дополнительной информации о значении справочника по коду этого значения. Поиск заданного значения в справочнике осуществляется с помощью POSTзапроса по URL в формате [base]/ValueSet/$lookup. Метод возвращает json с детализированной информацией о значении, которое соответствует коду значения из запроса.
Пример запроса:
POST [base]/ValueSet/$lookup?_format=json
{
«resourceType»: «Parameters»,
«parameter»: [
{
«name»: «system»,
«valueString»: «urn:oid:1.2.643.5.1.13.13.11.1117»
},
{
«name»: «code»,
«valueString»: «101»
}

]
}

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

Метод предназначен для проверки: принадлежит ли код значения из запроса указанному справочнику. Валидация значения в справочнике осуществляется с помощью POST-запроса по URL в формате [base]/ValueSet/$validate-code. Метод возвращает результат проверки значения справочника.
Пример запроса:
POST [base]/ValueSet/$validate-code?_format=json
{
«resourceType»: «Parameters»,
«parameter»: [
{
«name»: «system»,
«valueString»: «urn:oid:1.2.643.5.1.13.13.11.1117»
},
{
«name»: «code»,
«valueString»: «101»
}
]
}

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

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

ОДЛИ

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

ОДИИ

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

ОДР

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

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

Введение

Данный документ предназначен для практического применения интеграционных профилей, описанных в документе «Техническое приложение к регламенту информационного взаимодействия. Описание интеграционных профилей. Сервис ОДИИ» (далее — ОИП).
В документе описаны:
1. Особенности применения методов обмена данными
2. Бизнес логика процессов
3. Правила использования
4. Требования к передаваемым данным
5. Описание правил валидации данных.
Данный документ служит дополнением к требованиям, описанные в ОИП, и не заменяет их.
Методические рекомендации основаны на обработке вопросов участников информационного взаимодействия, поступающих разработчику сервиса, и не содержат всей поясняющей информации о сервисе ОДИИ.

Глоссарий

1. ОДИИ — подсистема обмена данными инструментальных исследований
2. ИИ — инструментальное исследование
3. DICOM- viewer — DICOM просмотрщик
4. OID — объектный идентификатор
5. WL — worklist (рабочий список диагностического оборудования)
6. UC — варианты использования
7. V — валидация
8. Bundle — тип ресурса, представляющий собой контейнер ресурсов, необходимых для передачи информации о заявке/результате. Подробно о ресурсе Bundle – см. http://fhirru.github.io/bundle.html
9. ДУЛ — документ удостоверяющий личность
10. Уникальный ключ — параметр, определяющий уникальность ресурса (Unique Key), в ОИП параметр указан с сокращением UK.

В документе принято следующее правило описания параметров методов ОДИИ:
1. [Ресурс].[Параметр1].[Параметр2]…[ПараметрN]
a. Параметры 1..N — вложенные параметры ресурса.

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

Правила валидации данных

Сервис осуществляет валидацию входных данных при вызовах методов ОДИИ.
Валидируются следующие данные:
1. Авторизационные данные, передаваемые в заголовках (headers) метода.
2. Данные передаваемые в пути (path) запроса.
Пример: передача GUID в GET запросах.
3. Данные передаваемые в теле (body) запроса.
a. Уникальность передаваемых данных (обрабатывается отдельно для каждого
ресурса).
b. Валидация структуры (передаваемые данные).
c. Валидация обязательности заполнения параметров.
d. Валидация значений параметров.
i. Тип данных.
ii. Значение согласно справочникам.

# Валидация Правило
Общие правила валидации параметров
V1 Параметр обязательный. Кратность: {1..1, 1..2, 1..*} Параметр должен быть передан и не должен быть пустым
V2 Тип данных uri ИЛИ oid Валидация параметров с типом данных uri. параметр должен передаваться по одной из схем:
1. ИЛИ urn:oid:{значение}
2. ИЛИ urn:uuid:{значение}
a. Только для параметра Bundle.entry.fullUr
V4 Параметр имеет тип Reference ● ИЛИ должна быть ссылка на существующий в
БД ресурс
● ИЛИ должна быть ссылка на передаваемый
ресурс в Bundle
V5 Кратность параметров Если параметр является массивом по FHIR И
количество передаваемых элементов ограничено в ОИП, то должно выполняться следующее:
1. Количество передаваемых элементов должно
быть в диапазоне указанной кратности параметра согласно ОИП
Кратность обозначается в ОИП: 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
проверяются на признак доступности:
PractitionerRole.active == true
Practitioner.active == true
Device.status == active.
Patient
V11
Уникальность Patient.identifier.system Patient.identifier.system должен быть уникальным в пределах массива Patient.identifier
V12 Допустимые значения Patient.identifier.system Patient.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.system Practitioner.identifier.system должен быть уникальным в пределах массива Practitioner.identifier
V18 Допустимые Practitioner.identifier.system Practitioner.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 Endpoint.status Список допустимых значений для Endpoint.status: active, off.
V22 Task.status заявки Task.status заявки не передается, кратность 0..0
V23 Task.status результата/результата без заявки Список допустимых значений для Task.status
результата/результата без заявки: in-progress,
completed
V24 Проверка Task.status результата/результата без заявки И DiagnosticReport.status 1. Если Task.status результата/результата без
заявки == in-progress, то DiagnosticReport.status
(Task.focus результата/результата без заявки) должен == partial
2. Если Task.status результата/результата без
заявки == completed, то DiagnosticReport.status
(Task.focus результата/результата без заявки) должен == final ИЛИ == appended
V25
Результат на отклоненную заявку Результат не может быть принят по заявке с
Task.status == rejected ИЛИ cancelled
V26
Результат по выполненной заявке Если заявка выполнена Task.status заявки ==
completed, то сервис принимает только результаты второго мнения (DiagnosticReport.status == appended)
по этой заявке
Заявка
V27 Источник финансирования ОМС Если в заявке источник финансирования
(ServiceRequest.orderDetail.coding.code) указан ОМС, то для пациента (ServiceRequest.subject.reference)
должен быть передан полис ОМС.
V28 Ссылки на пациента Значения следующих параметров:
— ServiceRequest.subject.reference
— Encounter.subject.reference
— Condition.subject.reference
должны совпадать с параметром Task.for.reference
V29
Валидация ссылок на разрешенные ресурсы Сервис ОДИИ контролирует передаваемые типы
ресурсов в параметрах типа reference. Параметр
должен содержать ссылку только на указанный
разрешенный ресурс
1. Task.focus.reference — ServiceRequest
2. Task.for.reference — Patient
3. Task.requester.reference — Organization
4. Task.owner.reference — Organization
5. ServiceRequest.subject.reference — Patient
6. ServiceRequest.requester.reference —
PractitionerRole
7. ServiceRequest.performer.reference — Device
8. ServiceRequest.supportingInfo.reference —
Observation, Condition
9. Encounter.subject.reference — Patient
10. Encounter.diagnosis.condition.reference —
Condition
11. Condition.subject.reference — Patient
V30
Проверка значения ServiceRequest.intent ServiceRequest.intent == filler-order
V31 Проверка передающей ИС Параметры:
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
Должны совпадать с параметром Task.identifier.system
Результат / результата без заявки
V32 Сравнение пациента с заявкой
(только для результата)
Значение параметра Task.for.reference результата должно совпадать с Task.for.reference заявки, передаваемая в параметре Task.basedOn результата
V33 Ссылки на пациента Значения следующих параметров:
— DiagnosticReport.subject.reference
— ImagingStudy.subject.reference
должны совпадать с параметром Task.for.reference
V34 Сравнение ServiceRequest
результата и заявки
Ресурс SeviceRequest, указанный в
DiagnosticReport.basedOn.reference, должен
соответствовать заявке, указанной в
Task.basedOn.reference результата
V35 Валидация ссылок на разрешенные ресурсы (только для результата) Сервис ОДИИ контролирует передаваемые типы
ресурсов в параметрах типа reference. Параметр
должен содержать ссылку только на указанный
разрешенный ресурс
1. Task.basedOn.reference — Task
2. DiagnosticReport.basedOn.reference —
ServiceRequest
V36 Валидация ссылок на разрешенные ресурсы Сервис ОДИИ контролирует передаваемые типы
ресурсов в параметрах типа reference. Параметр
должен содержать ссылку только на указанный
разрешенный ресурс
1. Task.focus.reference — DiagnosticReport
2. Task.for.reference — Patient
3. Task.requester.reference — Organization
4. Task.owner.reference — Organization
5. DiagnosticReport.subject.reference — Patient
6. DiagnosticReport.performer.reference —
PractitionerRole
7. ImagingStudy.subject.reference — Patient
8. ImagingStudy.interpreter.reference —
PractitionerRole
9. ImagingStudy.series.performer.actor.reference
— Device
10. Observation.performer.reference —
PractitionerRole
V37 Accession number (только для результата)

Accession number, передаваемый в результате,
должен совпадать. Значение следующих параметров должны совпадать:
1. Результат: ImagingStudy.identifier.value при
ImagingStudy.identifier.type.coding.code == ACSN

2. Заявка (Task.basedOn результата):
Task.identifier.value при Task.identifier.type.coding.code
== ACSN

V38 Пациент (только для результата) В Bundle должен отсутствовать параметр
Bundle.entry.resource.resourceType == Patient
V39 Проверка contentType Binary.contentType И DiagnosticReport.presentedForm.contentType должен равняться одному из принятых значений на проекте:
application/pdf
application/x-pkcs7-practitioner
application/x-pkcs7-organization
V40 Проверка передающей ИС Параметры:
1. Practitioner.identifier.assigner.display при
Practitioner.identifier.system = 1.2.643.5.1.13.2.7.100.5
2. Device.identifier.system
3. Endpoint.identifier.system
Должны совпадать с параметром Task.identifier.system
V41 Проверка передающей ИС (только для результата без заявки) Параметр:
1. Patient.identifier.assigner.display при
Patient.identifier.system = 1.2.643.5.1.13.2.7.100.5
Должны совпадать с параметром Task.identifier.system
V42 Соответствие contentType Параметры Binary.contentType И
DiagnosticReport.presentedForm.contentType должны совпадать для одного и того же переданного ресурса Binary
V43
Проверка УКЭП

В проверке участвуют ресурсы: Binary,
DiagnosticReport, PractitionerRole, Practitioner, Task
Если в ресурсе 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
a. Ресурс Practitioner вычисляется по цепочке
DiagnosticReport.performer.reference содержит ссылку на ресурс PractitionerRole. Параметр
PractitionerRole.practitioner.reference содержит ссылку на нужный ресурс Practitioner
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).

a. Ресурс Practitioner вычисляется по цепочке
аналогично пункту 1
3. Проверка ФИО (ресурс Practitioner) на
соответствие УКЭП (Binary.data с Binary.contentType ==
application/x-pkcs7-practitioner). Должно выполняться следующее:
a. Practitioner.name.family == полю SN подписи
b. Practitioner.name.given[0] == полю G[0] подписи c. Practitioner.name.given[1] == полю G[1] подписи.
Если G[1] отсутствует в подписи, то соответствие не проверяется.
Сравнение регистронезависимое.
4. Проверка ОГРН. ОГРН МО в подписи должен
совпадать с ОГРН МО, передаваемом в Bundle
a. ОГРН МО подписи == параметр ОГРН подписи
Binary.data с Binary.contentType == application/x-pkcs7-organization
b. ОГРН МО в Bundle == параметр
Organization.ogrn. Ресурс Organization взять по ссылке
Task.owner.reference передаваемого результата
5. Проверка даты результата на действие УКЭП.
Параметр DiagnosticReport.issued должен входить в период действия УКЭП (вычислить из документа Binary с Binary.contentType == application/x-pkcs7-practitioner).

$updatestatus
  Допустимые значения status Для parameter.valueString при parameter.name ==
status список допустимых значений [cancelled,
rejected]
  Проверка при передаваемом
status == cancelled
Если передается parameter.valueString == cancelled при parameter.name == status, то Task.status найденной заявки должен быть равен requested
  Проверка при передаваемом
status == rejected
Если передается parameter.valueString == rejected при parameter.name == status, то Task.status найденной заявки должен быть равен requested ИЛИ accepted

Ссылки на ресурсы

При передаче данных методами ОДИИ необходимо указывать связи между ресурсами.
Данные связи называются ссылками и указываются в соответствующих параметрах. Для таких параметров указывается тип данных Reference.
Пример связей:
1. В какой организации работает врач.
2. Какому пациенту создана заявка на исследование.
В методах ОДИИ используются два типа ссылок:
1. Ссылка на внутренний ресурс, передаваемый в Bundle.
2. Ссылка на уже созданный ранее ресурс.
В соответствии с этими типами ссылка должна передаваться определенной схемой.

Тип ссылки Описание Пример
1 На внутренний
ресурс
передаваемый в составе Bundle
Передается значение
параметра fullUrl
ссылаемого ресурса
«encounter»: {
«reference»:»urn:uuid:f0ceca14-6847-4ea4-
b128-7c86820da555 }
2 На созданный ранее ресурс Передается по схеме
[resourceType]/[GUID]
«subject»: {
«reference»:»Patient/a0a7a0e8-c445-455b8b2d-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/af2a113a-ed05-4d82-8633-bca6b76736d5»}

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

В данном разделе описана обязательность поддержки методов участниками
взаимодействия.
1. Направляющая МО — направляет пациента на исследование.
2. Целевая МО — организация, в которой проводится исследование пациенту.
Если МО является и направляющий и целевой, то необходимо обеспечить
поддержку методов всех необходимых методов.
1 усл. — условно обязательно.
1 — обязательно.


п/
п
Наименование метода Описание
метода
ИС направляющей МО ИС целевой МО
Обязательн
ость
Примечание Обязательн
ость
Примечание
1 POST
Patient
Передача
данных нового
пациента
(регистрация)
1 усл. усл: Данный
метод можно
заменить на
передачу ресурса Patient в
составе bundle
заявки
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
Patient в
составе
bundle
результата
без заявки
2 PUT Patient Обновление
данных
пациента,
зарегистрирова
нного в сервисе
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса Patient в
составе
bundle
заявки.
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса Patient в
составе
bundle
результата
без заявки. 
3 POST
Practitioner
Передача
данных нового
врача (регистрация)
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
Practitioner в
составе
bundle
заявки
(вместе с
ресурсом
PractitionerR
ole).
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
Practitioner в
составе
bundle
результата
(вместе с
ресурсом
PractitionerR
ole).
4 PUT
Practitioner
Обновление
данных врача,
зарегистрирова
нного в сервисе
1 усл. усл: Данный
метод можно заменить на
передачу
ресурса
Practitioner в
составе
bundle
заявки
(вместе с
ресурсом
PractitionerR
ole).
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
Practitioner в
составе
bundle
результата
(вместе с
ресурсом
PractitionerR
ole)
5 POST
Practitioner
Role
Передача
данных нового
врача
(регистрация)
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
PractitionerR
ole в
составе
bundle
заявки.
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
PractitionerR
ole в
составе
bundle
результата.
6 PUT
Practitioner
Role
Обновление
данных врача,
зарегистрирова
нного в сервисе
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
PractitionerR
ole в
составе
bundle
заявки.
1 усл. усл: Данный
метод можно
заменить на
передачу
ресурса
PractitionerR
ole в
составе
bundle
результата.
7 POST
Device
Передача
устройства
Не требуется   1 Необходимо
передать
все
устройства
в сервис
для обмена
данными
8 PUT Device Обновление
устройства
Не требуется   1 Необходимо
передать
все
устройства
в сервис
для обмена
данными
9 POST
Endpoint
Передача
данных PACS /
viewer
Не требуется   1 усл. усл:
необязатель
но для
передачи,
при условии
хранения
исследован
ий в ЦАМИ.
10 PUT
Endpoint
Обновление
данных PACS /
viewer
Не требуется   1 усл. усл:
необязатель
но для
передачи,
при условии
хранения
исследован
ий в ЦАМИ
11 POST
Schedule
Передача данных
устройства по
заявке
Не требуется   1 Обязательн
о для
подтвержде
ния заявки и
передачи
задания в
глобальный
worklist
12 PUT
Schedule
Обновление
данных
устройства по
заявке
Не требуется   1  
13 POST Bundle
заявки
Передача
заявки
1   Не требуется  
14 POST
Bundle
результата
Передача
результата
Не требуется   1  
15 POST
Bundle
результата
без заявки
Передача
результата без
заявки
Не требуется   1  
16 POST
Bundle без
результата
Передача
информации об
отсутствии
результата
Не требуется   1  
17 Task/_search Поиск заявок и
результатов
1   1  
18 GET
resource
Запрос
произвольного
ресурса в
сервисе
1   1  
19 $updatestatus Отмена /
отклонение
заявки
1 усл. Для
направляю
щей МО
поддержка
отмены
заявки (status =
cancelled)
1 усл. Для
направляю
щей МО
поддержка
отмены
заявки (status =
cancelled)

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

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

Минимально необходимая информация при передаче пациента:
1. ФИО (Отчество необязательно. Данные передаются согласно ДУЛ)
2. Пол
3. Дата рождения
4. Идентификатор пациента в МИС
Способы передачи данных пациента:
1. ИЛИ отдельным методом (POST Patient).
2. ИЛИ отдельным ресурсом Patient в составе Bundle заявки или результата без заявки
(POST Bundle заявки, POST Bundle результата без заявки).
a. При передаче Bundle результата сервис ожидает увидеть ссылку на
пациента, совпадающего с заявкой. Передача результата по заявке на
другого пациента запрещается.
Условия использования:
1. Если пациент передается отдельным методом, то при передаче заявок и
результатов не требуется передавать отдельный ресурс Patient, необходимо
передавать ссылку на пациента в соответствующих параметрах. Краткий сценарий
использования:
a. ИС передает пациента POST Patient.
b. ИС сохраняет GUID пациента в сервисе ОДИИ, возвращенный из успешного
ответа
c. GUID пациента используется для передачи ссылки на пациента.
Требования:
1. При повторной передаче пациента в сервис необходимо передавать всю
информацию по пациенту, а не только измененную. Иначе пациент будет обновлен
с последней переданной информацией.
a. Необходимо запросить данные пациента из сервиса, откорректировать и
передать в сервис.
2. Обязательно должен передаваться идентификатор пациента в МИС.
3. Запрещается:
a. Одновременная передача нескольких идентификаторов одного типа
(паспорт, полис и т.п.):
● нескольких полисов ОМС (ЕНП | временное св-во | полис старого
образца)
● несколько ДУЛ одного вида
Пример: нельзя передать ЕНП и временное св-во, нельзя передать
два паспорта РФ
b. Передача различных пациентов (разные физические лица) с одним
идентификатором МИС из одной МО.
c. Передача одного пациента (одно физическое лицо) с разными
идентификаторами МИС из одной МО.
Требования к передаче данных:
— обязательно передавать все известные идентификаторы пациента: СНИЛС, ДУЛ, полисы
— рекомендуется передавать все известные данные пациента (адрес по прописке и
регистрации, место рождения и др.)
Ограничения сервиса:
— передача заявки с типом оплаты «ОМС» возможна только в том случае, если для
пациента был передан полис ОМС. Передача заявки с типом оплаты «ДМС» возможна вне зависимости от переданного полиса ДМС.
— для пациента возможна передача только одного полиса ОМС (ЕП, временное св-во,
полис старого образца) и только одного ДУЛ данного вида (например, нельзя передать ЕП и временное св-во, или два паспорта РФ)

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

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

Для регистрации пациента в сервисе ОДИИ используется POST-запрос ресурса Patient.
Структура передаваемых данных в ресурсе Patient описана в документе «Описание
интеграционных профилей. Сервис ОДИИ».
Уникальность ресурса Patient определяется по следующим параметрам (уникальный ключ):
1. Patient.identifier.value
a. при identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5
2. Patient.identifier.assigner.display
a. при identifier.system = urn:oid:1.2.643.5.1.13.2.7.100.5
3. Patient.managingOrganization
При передаче ресурса Patient осуществляется поиск пациента в сервисе ОДИИ по
приведенным выше параметрам.
Правила обработки данных POST-запроса Patient:
1. Создается новый пациент, сервис в ответ возвращает json с созданным пациентом,
его идентификатором в сервисе ОДИИ и версией ресурса, если
● Пациент не найден в БД.
2. Происходит обновление пациента, сервис в ответ возвращает json с обновленным
пациентом, идентификатором в сервисе ОДИИ и новой версией ресурса, если
● Пациент найден в БД.
a. Важно: обновление ресурса Patient допускается только в том случае, если
уникальный ключ (набор параметров ресурса, определяющий его
уникальность), передаваемый в теле запроса, совпадает с ключом
обновляемого ресурса, найденного в БД.

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

Для обновления пациента используется PUT-запрос ресурса Patient. Структура
передаваемых данных в ресурсе Patient описана в документе «Описание интеграционных профилей. Сервис ОДИИ».
При обновлении ресурса Patient необходимо передавать
1. все параметры, в том числе и не изменившиеся
2. id ресурса в сервисе.
Правила обработки данных PUT-запроса Patient:
1. Производится обновление ресурса, если
● есть изменения в теле пациента, кроме параметров по которым
определяется уникальность ресурса (уникальность ресурса Patient)
2. Сервис ничего не изменяет и возвращает найденный ресурс Patient, если
● в теле ресурса Patient ничего не изменилось
3. Сервис возвратит ошибку, если
● ИЛИ указанный ресурс Patient не найден в БД.
● ИЛИ есть изменения в параметрах, по которым определяется уникальность
ресурса (уникальность ресурса Patient)
Важно: обновление ресурса разрешено ТОЛЬКО создателям данного ресурса (POST
Patient). В случае попытки изменения ресурса, заведенного другим ЛПУ или другой ИС, сервис возвратит ошибку.

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

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

Для передачи данных о враче в сервисе ОДИИ используется два ресурса:
1. Practitioner. Содержит общие сведения — идентификаторы врача и ФИО
2. PractitionerRole. Содержит данные о квалификации врача — должность,
специальность, и место работы, ссылка на врача
Способы передачи данных врача:
1. ИЛИ отдельными методами:
a. Сначала регистрировать общие сведения о враче POST Practitioner.
b. После успешной передачи врача зарегистрировать квалификацию врача
POST PractitionerRole.
2. ИЛИ передать оба ресурса в составе Bundle заявки, результата или результата без
заявки (POST Bundle заявки, POST Bundle результата, POST Bundle результата без
заявки).
Условия использования:
Если пациент врач передается отдельными методами POST Practitioner, POST
PractitionerRole, то при передаче заявок и результатов не требуется передавать отдельные
ресурсы, необходимо передавать ссылку только на зарегистрированный ресурс PractitionerRole в соответствующих параметрах.
В Bundle при передачи данных о враче главным ресурсом является PractitionerRole.
Краткий сценарий использования:
1. ИС передает пациента POST Practitioner
2. BC сохраняет GUID ресурса Practitioner, возвращенный в ответе.
3. ИС передает пациента POST PractitionerRole, используя GUID из шага 2 для
формирования ссылки на врача.
4. ИС сохраняет GUID ресурса PractitionerRole в сервисе ОДИИ, возвращенный в
ответе
5. GUID ресурса PractitionerRole используется для передачи ссылки на врача в
соответствующих параметрах заявки и результата
Если врач работает одновременно на нескольких должностях/специальностях, то
необходимо в сервис передать один ресурс Practitioner и соответствующие ресурсы
PractitionerRole.

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

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

Для регистрации врача в сервисе ОДИИ используется POST-запрос ресурса Practitioner.
Структура передаваемых данных в ресурсе Practitioner описана в документе «Описание интеграционных профилей. Сервис ОДИИ».
Уникальность ресурса Practitioner определяется по следующим параметрам:
1. Practitioner.identifier.value
2. Practitioner.Identifier.assigner.display
При передаче ресурса Practitioner осуществляется поиск врача в сервисе ОДИИ по
приведенным выше параметрам.
Правила обработки данных POST-запроса Practitioner:
1. Создается новый врач, сервис в ответ возвращает json с созданным врачом и его
идентификатор в сервисе ОДИИ, если
● Врач не найден в БД
2. Происходит обновление врача, сервис в ответ возвращает json с обновленным
врачом и его идентификатор в сервисе ОДИИ, если
● Врач найден в БД
a. Важно: обновление ресурса Practitioner допускается только для той ИС,
которая изначально зарегистрировала врача.

Передача квалификации врача (POST PractitionerRole)

Для регистрации квалификации врача в сервисе ОДИИ используется POST-запрос ресурса PractitionerRole. Структура передаваемых данных в ресурсе PractitionerRole описана в документе «Описание интеграционных профилей. Сервис ОДИИ».
Уникальность ресурса PractitionerRole определяется по следующим параметрам:
1. PractitionerRole.practitioner;
2. PractitionerRole.organization;
3. PractitionerRole.code;
4. PractitionerRole.specialty;
При передаче ресурса PractitionerRole осуществляется поиск квалификации врача в
сервисе ОДИИ по приведенным выше параметрам.
Правила обработки данных POST-запроса PractitionerRole:
1. Создается новый ресурс квалификации врача, сервис в ответ возвращает json с
созданным ресурсом и его идентификатор в сервисе ОДИИ, если
● Квалификация врача не найдена в БД
2. Происходит обновление ресурса квалификации врача, сервис в ответ возвращает
json с обновленным ресурсом и его идентификатор в сервисе ОДИИ, если
● Квалификация врача найдена в БД

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

Для обновления врача используется PUT-запрос ресурса Practitioner/PractitionerRole.
Операция обновления создает новую текущую версию ресурса. Структура передаваемых данных в
ресурсе Practitioner/PractitionerRole описана в документе «Описание интеграционных профилей.
Сервис ОДИИ».
При обновлении ресурса Practitioner/PractitionerRole необходимо передавать:
1. все параметры, в том числе и не изменившиеся,
2. id ресурса в сервисе.
Правила обработки данных PUT-запроса Practitioner/PractitionerRole:
1. Производится обновление ресурса, если
● есть изменения в теле ресурса, кроме параметров по которым определяется
уникальность ресурса (уникальность ресурса Practitioner, уникальность
ресурса PractitionerRole)
2. Сервис ничего не изменяет и возвращает найденный ресурс
Practitioner/PractitionerRole, если
● в теле ресурса Practitioner/PractitionerRole ничего не изменилось
3. Сервис возвратит ошибку, если
● ИЛИ указанный ресурс Practitioner/PractitionerRole не найден в БД.
● ИЛИ есть изменения в параметрах, по которым определяется уникальность
ресурса (уникальность ресурса Practitioner, уникальность ресурса
PractitionerRole)
a. Важно: обновление ресурса допускается только в том случае, если
уникальный ключ (набор параметров ресурса, определяющий его
уникальность), передаваемый в теле запроса, совпадает с ключом
обновляемого ресурса, найденного в БД.

Передача устройства

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

Передача устройства (POST Device)
Для регистрации устройства в сервисе ОДИИ используется POST-запрос ресурса Device.
Структура передаваемых данных в ресурсе Device описана в документе «Описание
интеграционных профилей. Сервис ОДИИ».
Уникальность ресурса Device определяется по следующим параметрам (уникальный ключ):
1. Device.identifier.system
2. Device.identifier.value
3. Device.owner.reference
При передаче ресурса Device осуществляется поиск устройства в сервисе ОДИИ по
приведенным выше параметрам.
Правила обработки данных POST-запроса Device:
2. Создается новый ресурс, сервис в ответ возвращает json с созданным устройством,
его идентификатором в сервисе ОДИИ и версией ресурса, если
● Устройство не найдено в БД.
3. Происходит обновление ресурса, сервис в ответ возвращает json с обновленным
устройством, идентификатором в сервисе ОДИИ и новой версией ресурса, если
● Устройство найдено в БД.
a. Важно: обновление ресурса допускается только в том случае, если
уникальный ключ (набор параметров ресурса, определяющий его
уникальность), передаваемый в теле запроса, совпадает с ключом
обновляемого ресурса, найденного в БД.

Обновление устройства (PUT Device)
Для обновления устройства используется PUT-запрос ресурса Device. Структура
передаваемых данных в ресурсе Device описана в документе «Описание интеграционных профилей. Сервис ОДИИ».
При обновлении ресурса Device необходимо передавать
1. все параметры, в том числе и не изменившиеся
2. id ресурса в сервисе.
Правила обработки данных PUT-запроса Device:
1. Производится обновление ресурса, если
● есть изменения в теле ресурса, кроме параметров по которым определяется
уникальность ресурса (уникальность ресурса Device)
2. Сервис ничего не изменяет и возвращает найденный ресурс Device, если
● в теле ресурса ничего не изменилось
3. Сервис возвратит ошибку, если
● ИЛИ указанный ресурс Device не найден в БД.
● ИЛИ есть изменения в параметрах, по которым определяется уникальность
ресурса (уникальность ресурса Device)
a. Важно: обновление ресурса допускается только в том случае, если
уникальный ключ (набор параметров ресурса, определяющий его
уникальность), передаваемый в теле запроса, совпадает с ключом
обновляемого ресурса, найденного в БД.

Передача данных PACS-сервера / viewer

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

Для передачи данных о PACS-сервере и viewer в сервисе ОДИИ используется один ресурс Endpoint. Для отличия данных используется параметр Endpoint.connectionType.code:
1. ihe-iid — для передачи данных о viewer
2. dicom-wado-uri — для передачи адреса PACS
Данные о PACS-сервере передаются для возможности поиска исследования по заявкам без результатов. Данные о viewer передаются для возможности составления ссылки на исследование и просмотра изображения во viewer.
В Bundle результата / результата без заявки при указании ссылки на ресурс Endpoint
(ImagingStudy.endpoint.reference) необходимо указывать ссылку на ресурс с данными viewer (connectionType.code == “ihe-iid”).

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

Передача данных PACS / viewer (POST Endpoint)
Для регистрации данных в сервисе ОДИИ используется POST-запрос ресурса Endpoint.
Структура передаваемых данных в ресурсе Endpoint описана в документе «Описание
интеграционных профилей. Сервис ОДИИ».
Уникальность ресурса Endpoint определяется по следующим параметрам (уникальный ключ):
1. Endpoint.identifier.system
2. Endpoint.identifier.value
3. Endpoint.managingOrganization.reference
4. Endpoint.connectionType
При передаче ресурса Endpoint осуществляется поиск ресурса в сервисе ОДИИ по
приведенным выше параметрам.
Правила обработки данных POST-запроса Device:
1. Создается новый ресурс, сервис в ответ возвращает json с созданными данными,
идентификатором в сервисе ОДИИ и версией ресурса, если
● Ресурс не найден в БД.
2. Происходит обновление ресурса, сервис в ответ возвращает json с обновленными
данными, идентификатором в сервисе ОДИИ и новой версией ресурса, если
● Ресурс найден в БД.
a. Важно: обновление ресурса допускается только в том случае, если
уникальный ключ (набор параметров ресурса, определяющий его
уникальность), передаваемый в теле запроса, совпадает с ключом
обновляемого ресурса, найденного в БД.

Обновление устройства (PUT Endpoint)
Для обновления данных используется PUT-запрос ресурса Endpoint. Структура
передаваемых данных в ресурсе Endpoint описана в документе «Описание интеграционных профилей. Сервис ОДИИ».
При обновлении ресурса Endpoint необходимо передавать
1. все параметры, в том числе и не изменившиеся
2. id ресурса в сервисе.
Правила обработки данных PUT-запроса Device:
1. Производится обновление ресурса, если
● есть изменения в теле ресурса, кроме параметров по которым определяется
уникальность ресурса (уникальность ресурса Endpoint)
2. Сервис ничего не изменяет и возвращает найденный ресурс Device, если
● в теле ресурса ничего не изменилось
3. Сервис возвратит ошибку, если
● ИЛИ указанный ресурс Endpoint не найден в БД.
● ИЛИ есть изменения в параметрах, по которым определяется уникальность
ресурса (уникальность ресурса Endpoint)
a. Важно: обновление ресурса допускается только в том случае, если
уникальный ключ (набор параметров ресурса, определяющий его
уникальность), передаваемый в теле запроса, совпадает с ключом
обновляемого ресурса, найденного в БД.

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

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

В сервисе ОДИИ обмен данными происходит на уровне сущностей:
1. Заявка
2. Результат
3. Результат без заявки
Сущность заявки можно ассоциировать с понятием «Направление», но при этом заявка включает в себя больше данных18:
● Сведения о пациенте (ФИО, пол, ДР, идентификаторы и т.п.).
● Сведения о враче (ФИО, пол, ДР, должность, специальность и т.п.).
● Общие сведения о заявке (идентификатор, дата, автор и т.п.).
● Информация о назначенных видах исследований и враче, сделавшем назначение.
● Данные о случае обслуживания, в рамках которого назначено исследование.
● Данные о состоянии пациента (диагнозы, информация о росте, весе пациента и
т.п.).
Для передачи заявки должен использоваться ресурс Bundle19 типа транзакция.
Bundle используется для передачи набора ресурсов.
В успешном ответе сервис вернет параметр Task.identifier.value с
Task.identifier.type.coding.code == ACSN, являющийся уникальным идентификатором заявки и однозначно определяющим исследование в сервисе ОДИИ (Accession number).
Требования:
1. Заявка должна всегда передаваться за один раз: полностью, с уникальным
идентификатором в МИС.
a. Не допускается:
i. Передача заявки частями.
ii. Передача заявок с одинаковыми идентификаторами в МИС.
2. Если источник финансирования в заявке ОМС, то для пациента должен быть
передан полис ОМС, см. валидации
Важно: заявка должна соответствовать одному исследованию (услуге), т.к.
идентификатор заявки (Task.identifier.value) должен быть уникальным для выполняемого исследования (ServiceRequest.code.coding).
Если в направляющей МО пациенту назначили несколько услуг, необходимо
отправить в сервис ОДИИ несколько POST Bundle заявок. В каждом запросе указать одно исследование.
Важно: заявка передается без статуса, статус назначает сервис ОДИИ:
1. при получении POST Bundle заявки назначается Task.status = requested,
ServiceRequest.status = active
2. при получении данных оборудования по заявке (POST Schedule) назначается Task.status = accepted, ServiceRequest.status = active
3. при получении неокончательного результата по заявке (POST Bundle результата)
назначается Task.status = in-progress, ServiceRequest.status = active
4. при получении окончательного результата / второго мнения по заявке (POST Bundle результата) Task.status = completed, ServiceRequest.status = active
Для понимания текущего статуса заявки, необходимо запросить заявку по идентификатору методом _search и посмотреть значение Task.status (см. Статусная модель).

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

Для передачи заявки используется POST-запрос ресурса Bundle. Ресурс Bundle
представляет собой контейнер ресурсов, необходимых для передачи информации о заявке.
Структура передаваемых данных описана в документе «Описание интеграционных профилей.
Сервис ОДИИ».
Уникальность заявки (ресурса Bundle) определяется по следующим параметрам:
1. Task.identifier.value
2. Task.identifier.system
3. Task.request.reference
4. Task.intent
При повторном добавлении заявки сервис ОДИИ возвращает ошибку: «Повторное
добавление заявки».
При передаче ресурсов Patient, PractitionerRole, Practitioner в составе Bundle
осуществляется поиск этих ресурсов по уникальным параметрам в сервисе ОДИИ.
Правила обработки данных Practitioner/Patient/PractitionerRole
1. Создается ресурс передаваемый в Bundle, сервис возвращает в ответ json Bundle заявки
с созданным ресурсом и идентификатором в сервисе, если
● ресурс (Practitioner/Patient/Encounter) не найден в БД
2. Происходит обновление ресурса, сервис возвращает в ответ json Bundle заявки с
обновленным ресурсом и идентификатором в сервисе, если
● ресурс (Practitioner/Patient/Encounter) найден в БД

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

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

Сервис ОДИИ поддерживает передачу данных по следующим схемам:
1. Передавать результат неокончательный результат. Для этого необходимо указать
следующие статусы — Task.status = in-progress и DiagnosticReport.status = partial.
a. Неокончательным результатом считатеся результат, по которым
планируется добавление информации в дальнейшем. Например:
i. Выполнено исследование. ИС получила данные об изображении.
ii. Данные изображения передаются в сервис ОДИИ (Task.status = inprogress)
iii. Врач описывает исследование, составляет протокол. Исследование
выполнено в целевой МО.
iv. ИС отправляет в сервис ОДИИ изображение и протокол, при
возможности текстовые данные результатов (описание/заключение)
(Task.status = completed)
2. Для передачи окончательного результата необходимо в передаваемой результате
указать Task.status = completed и DiagnosticReport.status = final.
a. при отправлении окончательного результата, заявка становится помеченная
как выполненная. Далее на выполненную заявку принимаются только вторые
мнения.
b. окончательный результат должен содержать все переданные результаты
ранее — если в сервис был ранее передан неокончательный результат с
изображением, а в окончательном результате передается протокол, то
окончательный результат должен содержать изображение и протокол.
3. Для передачи второго мнения необходимо в передаваемой результате указать
Task.status = completed и DiagnosticReport.status = appended.
Необходимо:
1. При передаче результата, содержащего текстовую часть, необходимо передавать
три ресурса – описание, заключение и протокол PDF
Допускается:
1. Передавать в результате не те услуги (виды назначений на ИИ), которые были
заказаны в заявке
Не допускается:
1. Передавать результат как выполненный, если в нем нет протокола исследования.

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

Результаты инструментальных исследований передаются в следующих ресурсах:
1. Основные ресурсы:
a. ImagingStudy — передача информации об изображении. Содержит
уникальные идентификаторы исследования (Study UID), ссылку на viewer
b. Observation — передача текстового результата инструментального
исследования (описание, заключение).
2. Дополнительные:
a. Binary — pdf документ протокола инструментального исследования, УКЭП
В общем случае результат может быть передан тремя способами:
— только информация об изображении (передается ресурс ImagingStudy со ссылкой на
вьюер, передается в ресурсе Endpoint)
— только описание (передаются обязательно два ресурса Observation – отдельно описание и заключение, и один ресурс Binary с протоколом PDF),
— информация об изображении и описание. Правила формирования и требования к передаче отражены в таблице ниже.

Вариант передачи Ситуация Ситуация
Только информация
об изображении
Информация об изображении получена
с оборудования, но описания пока нет
Данные по изображению
(ImagingStudy 1..1)
Только описание Информации об изображении нет и не
будет, но есть описание
Описание, заключение
(Observation 2..2), протокол PDF
(Binary без УКЭП 1..1, Binary с УКЭП 3..3 )
Информация об
изображении и
описание
Есть и информация по изображению, и
описание
Данные по изображению
(ImagingStudy 1..1), описание,
заключение (Observation 2..2),
протокол PDF (Binary без УКЭП 1..1, Binary с УКЭП 3..3 )
Второе мнение Изображение ранее описано Описание, заключение
(Observation 2..2), протокол PDF
(Binary без УКЭП 1..1, Binary с УКЭП 3..3 )

Если передается Observation, то можно передавать только два Observation с разными code
— описание (code == 1) и заключение (code == 2). Любые другие варианты не допускаются. Если
передается Observatioin — Binary обязательны к передаче
Можно передавать или один Binary с «contentType» : «application/pdf», или три Binary с
«contentType» : «application/pdf», «contentType» : «application/x-pkcs7-practitioner», «contentType» :
«application/x-pkcs7-organization». Любые другие варианты не допускаются. Если передается Binary
— Observatioin обязательны к передаче

Ресурс Observation результата

Ресурс Observation, передаваемый в Bundle результата, предназначен для передачи
текстового результата инструментального исследования (в Bundle для передачи заявки этот же ресурс используется для указания других параметров).
В Оbservation результата передается:
1. Описание исследования.
2. Заключение.
Каждый результат передается отдельным ресурсом Оbservation.
Содержание ресурса Observation определяется по значению параметра code
согласно справочнику 1.2.643.2.69.1.1.1.119.

Значение code.coding.code Назначение
1 Для передачи описания исследования
2 Для передачи заключения

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

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

Для передачи результата инструментального исследования используется POST-запрос ресурса Bundle. Ресурс Bundle представляет собой контейнер ресурсов, необходимых для передачи информации о результате. Структура передаваемых данных описана в документе
«Описание интеграционных профилей. Сервис ОДИИ».
Уникальность результата (ресурса Bundle) определяется по следующим параметрам:
1. Task.identifier.value
2. Task.identifier.system
3. Task.request.reference
4. Task.intent
При повторном добавлении результата сервис ОДИИ возвращает ошибку: «Повторное добавление результата».

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

Для передачи результата инструментального исследования без заявки используется
POST-запрос ресурса Bundle. Структура передаваемых данных описана в документе «Описание интеграционных профилей. Сервис ОДИИ».
Уникальность результата без заявки (ресурса Bundle) определяется по тем же параметрам, что передача результата на заявку (Уникальность результата).
При повторном добавлении результата сервис ОДИИ возвращает ошибку: «Повторное добавление результата».
В Bundle результата без заявки должны передаваться те же ресурсы, что и в Bundle
результата по заявке. Главные отличия от Bundle результата по заявке:
1. В Bundle результата без заявки не передаются параметры Task.basedOn,
DiagnosticReport.basedOn
2. В Bundle результата без заявки можно передать ресурс Patient.

Статусная модель

Заявка

Task (original-order)

Task.status Наименование Определение Условия присвоения
статуса
Из какого статуса
можно переходить
requested Передано Направляющая МО
зарегистрировала заявку в
сервисе
Заявка передается
первый раз в сервис
начальный статус
accepted Принято Целевая МО
(потенциальный
исполнитель) согласился
выполнить заявку, но еще
не начал работу
Существующую заявку
приняли методом
POST Schedule.
Принятой заявкой
считаем заявку для
которой есть
следующие данные:
плановая дата-время
устройство, на
котором планируется
выполнение
исследования
тип модальности
устройства, на
котором планируется
выполнение
исследования
requested
rejected
Отклонено Целевая МО
(потенциальный
исполнитель) признала
заявку необоснованной.
Заявку отклонили
методом $updatestatus
ИЛИ заявка получена
из УО со статусом 0
requested
accepted
cancelled Отменено Заявка отменена
методом $updatestatus
Заявка отменена
методом $updatestatus
requested
in-progress В ходе
выполнения
Начато оказание
медицинской помощи в
целевой МО
Условие:
На заявку передан
Bundle результата с
Task.status == inprogress при
Task.intent == reflexorder
requested
accepted
completed Завершено Завершено оказание
медицинской помощи в
целевой МО
На заявку передан
Bundle результата с
Task.status ==
completed при
Task.intent == reflexorder
accepted
in-progress

ServiceRequest

ServiceRequest.status Наименование Определение Условия присвоения
статуса
Из какого
статуса можно
переходить
active Активно Готово к
исполнению
Ресурс создан в сервисе
Или заявка снова
доступна после
отклонения результата
Начальный
статус, completed
completed Завершено Услуга
оказана
Сервис получил Bundle результата с
DiagnosticReport.status ==
final
active
revoked Отозвана Услугу не
требуется
выполнять
Заявку отклонили или
отменили
active

Encounter

Encounter.status Наименование
planned Запланировано
arrived Прибыл
triaged Произведена оценка состояния пациента
in-progress Начато оказание мед. помощи
onleave Пациент находится в отпуске
finished Законченный случай
cancelled Отменено до оказания мед. помощи
entered-in-error Ошибочно переданный случай обслуживания
unknown Неизвестно

Observation (заявки)

Observation.status Наименование
final Окончательный

Результат

Task (reflex-order)

Task.status Наименование Определение Условия присвоения
статуса
Из какого статуса
можно переходить
in-progress В ходе
выполнения
Начато
оказание
медицинской
помощи в
целевой МО
Передаваемый
DiagnosticReport имеет
DiagnosticReport.status ==partial
Начальный статус
completed Завершено Завершено
оказание
медицинской
помощи в
целевой МО
Передаваемый
DiagnosticReport имеет
DiagnosticReport.status ==final
Начальный статус
in-progress
cancelled Отменено   (Не реализовано) in-progress
completed

DiagnosticReport

DiagnosticReport.status Наименование Определение Условия
присвоения
статуса
Из какого статуса
можно переходить
partial Частично Результат
передан не
полностью
Результат
неокончательный
Начальный статус
final Окончательно Окончательный
результат
  Начальный статус
partial
appended Прилагается Второе мнение   Начальный статус
final
cancelled Отменена Результат
отменен
Не реализовано partial
fina

ImagingStudy

ImagingStudy.status Наименование
available Доступно

Device

Device.status Наименование
active Доступно
inactive Недоступно

Endpoint

Endpoint.status Наименование
active Доступно
off Больше не используется

Интеграции

Сервис ОДИИ поддерживает различные интеграции в зависимости от региона. Основные участники информационного взаимодействия:
1. ИС направляющей МО.
a. Учет пациентов,
b. Учет направляющих врачей,
c. Учет случаев обслуживания,
d. Формирование заявок (направление).
2. ИС целевой МО
a. Учет врачей, утвердивших результат,
b. Учет оборудования,
c. Подтверждение заявок,
d. Формирование результатов исследования,
e. Локальный worklist
i. Учет заданий для модальности.
3. Подсистема ОДИИ
a. Учет заявок,
b. Учет результатов,
c. учет пациентов, которым назначено исследование.
d. учет направляющих врачей, врачей исполнителей.
e. учет информации об устройствах (диагностических аппаратов).
f. учет информации о PACS-серверах и просмотровщиках.
g. Глобальный worklist
i. Учет заданий для модальности.
4. Подсистема MPI
a. Пациенты
5. Глобальный worklist
a. Учет заданий для модальности.
6. ЦАМИ/PACS сервер
a. Учет изображений и протоколов исследований.
b. Учет PACS-серверов
Дополнительно в информационном взаимодействии могут участвовать следующие
системы:
1. Подсистема УО
a. Учет направлений
2. Портал врача
a. Просмотр результатов исследований
3. ИЭМК
a. Выгрузка результатов исследований в фед. проекты

Задачи выполняемые сервисом ОДИИ при интеграциях:
1. Подсистема УО. Получение направления.
a. Сервис ОДИИ отслеживает сообщения УО в сервисе оповещений.
b. Сервис ОДИИ запрашивает подробные данные заявки из УО и сохраняет в БД,
предварительно валидируя по своим правилам.
2. Глобальный worklist. Отправка задания.
a. После получения данных заявки и данных оборудования по заявке (Schedule) сервис ОДИИ отправляет данные в глобальный worklist.
3. ЦАМИ. Поиск исследования
a. Сервис ОДИИ осуществляет поиск исследования по заявкам без результатов. Поиск
производится по PACS, хранящиеся в сервисе ОДИИ в ресурсах Endpoint с
Endpoint.connectionType == “dicom-wado-rs”, и по accession number заявки
(Task.identifier.value с Task.type.coding.code == “ACSN”). При нахождение результата
исследования, сервис ОДИИ сохраняет некончательный результат с данными
изоборажения (ImagingStudy).

Особенности использования метода /_search

Для поиска заявок и результата в сервисе ОДИИ используется стандартный FHIR метод поиска ресурсов POST Task/_search. При поиске необходимо использовать параметры согласно FHIR и согласно параметрам, участвующим в обмене сервиса ОДИИ (см. документ ОИП).
Полное описание метода _search — https://www.hl7.org/fhir/search.html
Полное описание параметров поиска ресурса Task — http://hl7.org/fhir/task.html#search
Если в поиске требуется указать сразу несколько значений, то необходимо перечислять их в параметре valueString через запятую.