ОДИИ

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

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

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

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

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

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

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

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

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

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

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

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

1. Добавление заявки. При добавлении заявки в подсистему ОДИИ передается информация о пациенте, которому назначено исследование и заявка. При этом пациент:

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 также опубликованы в сервисе Терминологии).

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

При передаче любого значения с использованием справочника необходимо
передавать в том числе используемую версию справочника. Допускается передача значений только по актуальной версии справочника. При валидации значений сервисом значения, передаваемые без указания версии справочника или с указанием неактуальной версии, не проходят валидацию и не принимаются сервисом. Передача значений, отсутствующих в актуальной версии справочника, невозможна.
При использовании справочника медицинских организаций: в случае, если в
справочнике для учреждения зарегистрированы все его подразделения, необходимо передавать информацию от имени соответствующего подразделения. Передача информации от имени головного учреждения в данном случае не допускается. При передаче заявки на исследование необходимо указывать в заявке, данных пациента и случае обслуживания то учреждение или подразделение (если зарегистрировано в справочнике), где проходит лечение пациент (открыт случай обслуживания и создана заявка). 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.

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

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

Передача пациента (POST Patient).
Обновление пациента (PUT Patient).
Передача врача и квалификации (POST Practitioner, PractitionerRole).
Обновление врача и квалификации (PUT Practitioner, PractitionerRole).
Передача устройства (POST Device).
Обновление устройства (PUT Device).
Передача данных PACS-серверов и viewer (POST Endpoint).
Обновление данных PACS-серверов и viewer (PUT Endpoint).
Передача расписания (POST Schedule).
Обновление расписания (PUT Schedule).
Передача заявки (POST Bundle заявки).
Передача результата (POST Bundle результата).
Передача результата без заявки (POST Bundle результата без заявки).
Запрос заявок / результатов (Task/_search).
Отмена/отклонение заявки ($updatestatus)
Запрос ресурсов (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	Период действия для паспорта и полиса. Вложенные параметры: start — дата начала периода 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 — указывается код значения из справочника. Все параметры обязательные.

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 через запятую.