ОДР

Описание сервиса ОДР

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

  1. Настоящее описание интеграционных профилей модуля «Обмена данными рецептов» (далее – Описание) определяет механизмы информационного  взаимодействия медицинских информационных систем (далее – МИС), систем обеспечения медицинскими ресурсами (далее – СОМР) и сервиса «Обмен данными рецептами» (далее – сервис ОДР), входящих в состав Регионального сегмента Единой
    государственной системы в сфере здравоохранения.
  2. Описание предназначено для организаций-разработчиков, осуществляющих сопровождение эксплуатируемых информационных систем и разработку новых систем
  3. В рамках информационного взаимодействия сервис ОДР поддерживает получение следующих сведений от сторонних информационных систем:
    • Информация о пациенте (идентификатор в ИС, пол и дата рождения, ФИО и т.д.).
    • Информация о враче (идентификатор в ИС, ФИО и т.д.).
    • Информация о льготе.
    • Информация о рецепте.
  4. Документ содержит описание методов сервиса ОДР, которые должны поддерживать сторонние информационные системы для обеспечения автоматизированного информационного взаимодействия.

Определения, обозначения и сокращения

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

При описании ресурсов и используемых параметров используется понятие
«Кратность». Кратность — это нижняя и верхняя граница того, сколько раз элементу
разрешено появляться в ресурсе (см. описание параметров), или ресурсу в Bundle (см.
структуру Bundle), при этом используются следующие обозначения:
0..1 — минимальное количество элементов ноль (параметр может не
передаваться), максимальное один. Интерпретируется как необязательный параметр;
0..* — минимальное количество элементов ноль (параметр может не
передаваться), максимальное количество элементов не ограничено. Интерпретируется как
необязательный параметр;
1..1 — минимальное количество элементов один, максимальное один. Всегда
передается один элемент. Интерпретируется как обязательный параметр;
1..2 — минимальное количество элементов один, максимальное два.
Интерпретируется как обязательный параметр;
2..2 — минимальное количество элементов два, максимальное два. Всегда
передается два элемента. Интерпретируется как обязательный параметр;
1..* – минимальное количество элементов один, максимальное количество
элементов не ограничено. Интерпретируется как обязательный параметр.

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

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

Процесс проведения
ОДР — сервис Обмена Данными Рецептов — предназначен для учета лекарственных
препаратов (ЛП), специализированных продуктов лечебного питания (СПЛП) и
медицинских изделий (МИ), назначенных (выписанных) пациенту.
Назначения могут быть оформлены:
• при амбулаторном лечении пациента — с использованием медицинского
документа «Рецепт»
• при стационарном лечении пациента — с использованием медицинского
документа «Лист назначений»
В текущей версии ПО поддерживается информационное взаимодействие при
работе с рецептами. Листы назначения не поддерживаются.
Общая схема информационного взаимодействия в каждом конкретном случае
определяется на этапе технического проектирования. Фактические роли и права
участников информационного взаимодействия определяются предоставленными им
правами доступа).
Поставщиком документов о назначении является медицинская информационная
система (МИС, английская интерпретация Hospital information system, HIS)
Хранилищем документов о назначении является сервис обмена данными рецептов
(ОДР, английская интерпретация Prescription repository, PR)
Потребителем документов о назначении является система обеспечения
медицинскими ресурсами (СОМР, английская интерпретация Pharmacy dispensing
information system, PDIS)
В зависимости от требований региона к сервису, могут быть реализованы различные
схемы взаимодействия информационных систем с сервисом. МИС и СОМР могут изменять статусы рецепта, проставляя отметки о порче рецепта, о постановке на отложенное обслуживание, об отпуске рецепта. Сервис ОДР может выгружать информацию в ФР ЛЛО

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

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

  1. Учет информации о пациентах, которым назначено лечение.
  2. Учет информации о медперсонале
  3. Централизованный учет рецептов и отпуска по рецепту.
  4. Предоставление информации по выписанным рецептам и отпускам по рецепту.

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

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

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

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

Информационный обмен осуществляется в соответствии со стандартом FHIR® (Fast
Healthcare Interoperability Resources), разработанным организацией HL7. Используемая версия FHIR R4. Подробное описание стандарта доступно по следующим ссылкам:

  • http://hl7.org/fhir/R4/index.html
  • http://fhir-ru.github.io/summary.html

В качестве протокола взаимодействия используется RESTful API (использование
REST-протокола в FHIR® – см. http://fhir-ru.github.io/http.html). Данные необходимо
передавать в формате JSON, должен присутствовать http заголовок content-type:
application/json
Сервис поддерживает три основных метода:

  • передача ресурса (Patient, Coverage, Practitioner);
  • передача бандла рецепта;
  • запрос ресурсов

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

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

Authorization: N3[пробел][Авторизационный токен]

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

Для передачи данных в сервис необходимо передавать в заголовке сообщения
заголовок вида content-type: application/json

Текстовая информация, передаваемая в запросах, должна передаваться в
кодировке UTF8 (RFC 3629). Запрещается передача имени, отчества инициалами, а также записей вида «.», «нет», «нету» в случае, если отчество пациента отсутствует. Фамилия, имя, отчество должно начинаться с большой буквы, далее в нижнем регистре. Остальная текстовая информация передается регистром «Как в предложениях» или в нижнем регистре. Передача текста в верхнем регистре, за исключением аббревиатур, не допускается.

Все данные типа дата-время (кроме даты рождения пациента) следует передавать в
сервис в формате YYYY-MM-DDThh:mm:ss[.SSS]±hh:mm (стандарт ISO8601). Допускается, но не рекомендуется передача данных в формате YYYY-MM-DD и YYYY-MMDDThh: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 по структуре и содержанию.
Сервис возвращает ресурсы с автоматически присвоенными дополнительными
идентификаторами, не описанными в ОИП. Интегрированные системы должны корректно обрабатывать идентификаторы, учитывая только те, что описаны в ОИП.
Порядок следования ресурсов в запросе, параметров в ресурсе не нормируется и
может зависеть от способа передачи информации в сервис, поэтому нельзя
ориентироваться на порядковый номер какого-либо элемента в структуре.
При передаче данных врача, пациента необходимо формировать параметр
name.text, при формировании , льготы, рецепта – параметр reference.display, содержащий ФИО врача или пациента. Эти параметры должны формироваться следующим образом: [Фамилия][один пробел][Инициал имени][ точка][ один пробел][Инициал отчества][точка], например: «text»: «Щербинина А. В.». ФИО, передаваемые в параметре reference.display должны точно совпадать с параметром name.text того ресурса, на который дается ссылка.
Если в МИС отсутствует информация об идентификаторах пациента, врача,
квалификации врача в сервисе ОДР, необходимая для формирования рецепта, эта
информация должна быть предварительно запрошена из сервиса методами поиска:
— поиск пациента по СНИЛС (должен возвращаться один результат поиска);
— поиск врача по СНИЛС (должен возвращаться один результат поиска);
— поиск квалификации врача по идентификатору врача (может возвращаться
несколько результатов поиска, из которых необходимо выбрать нужный по месту работы, должности, специальности, указанной в квалификации врача)

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

Сервис осуществляет валидацию входных данных при вызовах любых методов. В
ответ на запрос сервис возвращает HTTP код состояния и ответ. Основные коды и их
значение указаны в таблице ниже.
Если валидация прошла успешно, то сервис возвращает успешный ответ (200, 201),
включающий в себя определенные параметры (в зависимости от типа запроса):
если передавался отдельный ресурс, возвращается переданный ресурс, в котором
также передаются:
• id — GUID созданного ресурса (присваивается при создании записи в БД,
используется для формирования ссылки на ресурс),
• meta — мета данные,
• meta.versionId — версия id ресурса в сервисе ОДР,
• meta.lastUpdated — дата-время последнего обновления ресурса
если передавался ресурс Bundle рецепта, возвращается Bundle, в котором
передаются:
• id — GUID Bundle в сервисе (присваивается при создании записи в БД,
используется в служебных целях)
• entry – массив переданных в запросе ресурсов в виде entry, содержащих для
каждого ресурса параметры:
o fullUrl (переданный в запросе параметр fullUrl преобразуется в
ссылку на ресурс для дальнейшего запроса его в сервисе — на новый
ресурс или ссылка на найденный в БД ресурс),
o resource (непосредственно переданный ресурс),
o response (status (201-created), location –ссылка на ресурс)
В случае, если передавался запрос информации, возвращается ресурс parameter,
содержащий массив данных (ресурсы и другая информация) в соответствии с типом
запроса.
Если валидация прошла неуспешно, то сервис возвращает ошибку (400-504), а
также параметр issue, содержащий массив с данными по обнаруженным ошибкам:
• code — код ошибки
• diagnostics — текст ошибки
• location — массив параметров, в которых обнаружена данная ошибка.

№
п/п		 Код Описание Примечание
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 Сервис недоступен. Таймаут Необходимо обратиться в техническую поддержку

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

Справочники, используемые в сервисе ОДР, опубликованы в «Сервисе
Терминологии». Описание сервиса Терминологии и правила взаимодействия с ним
приведены по ссылке: http://api.netrika.ru/docs.php?article=Terminology.
Для каждого справочника в Настоящем документе указан его OID (объектный
идентификатор). Перечень присвоенных корневых OID:

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

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

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

 

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

Примеры справочников для региона приводятся на тестовой площадке сервиса
Терминология по адресу http://rХХ-rc.zdrav.netrika.ru/nsiui , где ХХ – код региона

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

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

  1. Передача пациента (POST Patient)
  2. Обновление пациента (PUT Patient)
  3. Передача льготы (POST Coverage)
  4. Обновление льготы (POST Coverage)
  5. Передача врача (POST Practitioner)
  6. Обновление врача (PUT Practitioner)
  7. Передача рецепта (POST Bundle рецепта)
  8. Запрос ресурсов (GET resource)
  9. Отмена рецепта со стороны МИС ($cancelprescription)
  10. . Изменение статуса рецепта со стороны СОМР ($updatestatus)
  11. Поиск врача и пациента по СНИЛС
  12. Поиск льгот пациента

Примеры использования методов для региона приводятся на тестовой площадке
сервиса ОДР по адресу http://rХХ-rc.zdrav.netrika.ru/exlab_example/ , где ХХ – код региона
Для корректной работы с сервисом ОДР информационная система также должна
поддерживать методы работы с сервисом Терминологии. Минимально необходимо
поддерживать метод «Запрос значений справочника». Описание данного метода в данном документе приведено в справочном порядке

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

Для регистрации пациента в сервисе ОДР используется POST-запрос ресурса Patient.
В качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/Patient?_format=json. В ответе сервис возвращает json с созданным пациентом и его идентификатором в сервисе ОДР.
Уникальность пациента проверяется по СНИЛС. Многократная передача одного и
того же пациента из одной и той же МИС с разными идентификаторами МИС не
допускается.

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

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

№
п/п 		Параметр Тип Кратность Описание
1 identifier identifier 1..* Идентификатор пациента. Указывает идентификатор
пациента в передающей системе, СНИЛС(UK), полис ОМС (ЕНП), ДУЛ. Идентификатор в системе –
обязательный параметр
1.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.
— Для ДУЛ допустимые значения (1-18),
— для СНИЛС 223,
— для полисов ОМС (226-228), o для полисов ДМС 240.
1.2 identifier.value string 1..1 Значение для идентификатора или для документа.
Для идентификатора в МИС/РИС указывается [идентификатор в МИС/РИС] (UK)
Для паспорта и свидетельства о рождении указывается [Серия]:[Номер]
Для СНИЛС, страхового полиса указывается:
— [Серия полиса]:[Номер полиса] – для полиса
старого образца
— [Номер полиса] – для СНИЛС, полиса нового
образца и временного свидетельства
В серии допускаются цифры и буквы русского и
латинского алфавита. Между символами серии
допускается один пробел (10 АА).
В номере не должны использоваться разделители
(пробелы, тире и т.д.), допускаются только цифры.
В настройках сервиса может быть включена валидация:
— серии и номера документа для документов Паспорт
гражданина РФ, Свидетельство о рождении РФ,
Загранпаспорт гражданина РФ по маске, указанной в
справочнике 1.2.643.5.1.13.13.99.2.320
«Классификатор документов, удостоверяющих
личность гражданина Российской Федерации»;
— номера ЕНП по контрольной сумме;
— номера СНИЛС по правилам ПФР РФ
1.3 identifier.period Period 0..1 Период действия. Вложенные параметры:
— start — дата начала периода.
— end — дата окончания периода.
1.4 identifier.assigner string 1..1 усл Указывается OID передающей ИС для идентификатора пациента (UK)
Для ДУЛ – наименование выдавшей организации.
Для полиса ОМС любого типа указывается 1.2.643.5.1.13.2.1.1.635.[код страховой компании]
Для полиса ДМС – наименование СМО ДМС.
Для СНИЛС – «ПФР».
Вложенные параметры:
— reference: Ссылка на организацию, передающей
пациента в формате Organization/GUID, где GUID –
идентификатор организации по справочнику
1.2.643.2.69.1.1.1.64 (Auth)
— display: OID передающей ИС (Auth)
2 active boolean 1..1 Признак активности записи. true – запись активна, может использоваться, false – запись неактивна, не может использоваться
3 name HumanName 1..2* Информация о ФИО пациента.
3.1 name.family string 1..1 Фамилия
3.2 name.given string 1..2 Имя, отчество. Сначала указывается Имя. Отчество
передается при наличии.
3.3 name.text string 1..1 Имя, отчество. Сначала указывается Имя. Отчество передается при наличии.
4 gender code 1..1 Код пола пациента (справочник FHIR. OID: 1.2.643.2.69.1.1.1.40).
5 birthDate Date 1..1 Дата рождения. Формат: yyyy-MM-dd.
6 address Address 0..2 Информация об адресе пациента (по регистрации, по фактическому проживанию или оба)
6.1 address.extension   0..4 Расширение формата для передачи дополнительных
данных адреса:
— код вида места жительства пациента (город/село). В
параметре url указывается ссылка на справочник в параметре valueCodeableConcept
код места жительства по справочнику OID
1.2.643.5.1.13.13.11.1042;
— код ФИАС адреса. В параметре url указывается ссылка , в
параметре valueString AOGUID адресного объекта по
ФИАС»;
— код ФИАС дома. В параметре url указывается ссылка , в
параметре valueString HOUSEGUID здания по ФИАС»;
— номер квартиры. В параметре url указывается ссылка , в
параметре valueString номер квартиры»
6.2 address.use code 1..1 Тип адреса (справочник FHIR. OID:
1.2.643.2.69.1.1.1.41)
home — Адрес проживания.
temp — Адрес регистрации.
6.3 address.text string 1..1 Адрес строкой
6.4 address.line string 0..4 Улица, номер дома, номер корпуса, номер квартиры
(массив), необходимо придерживаться порядка:
Первая строка в массиве line всегда улица
Если строк две, то вторая — дом
Если строк три, то вторая — дом, третья квартира
Если четыре, то вторая дом, третья корпус, четвертая
квартира
Префиксы (ул., д., кор., стр., кв.) должны отделяться от
значения точкой или точкой и пробелом. Пример:
«line»: [«ул. Оптиков», «д. 6″,»кв. 220»]
6.5 address.state string 0..1 Регион. Указывается двузначный код субъекта РФ по справочнику 1.2.643.5.1.13.13.99.2.206
6.6. address.city string 0..1 Город. Префикс (г., пос., дер.) должен отделяться от значения точкой.
6.7. address.district string 0..1 Район
6.8. address.postalCode string 0..1 Почтовый индекс
6.9 address.period Period 0..1  Период регистрации, проживания. Вложенные параметры:
— start — дата начала периода.
— end — дата окончания периода.
6.10
 address.country string 0..1 Код страны гражданства по ОКСМ по справочнику 1.2.643.5.1.13.13.99.2.545. Передается
значение поля «Цифровой идентификатор». Для
граждан России 643. Для лиц без гражданства 000.
7 telecom ContactPoint 0..1 Телефон пациента. Вложенные параметры (все параметры обязательны):
— system — тип данных (всегда передается phone).
— use — тип телефона (home – домашний телефон, work
– рабочий, mobile — мобильный).
— value — значение номера телефона в формате +7(ХХХ)ХХХХХХХ

* Передача второго набора ФИО пациента допускается для передачи предыдущей
ФИО пациента (до смены фамилии), при этом Patient.name должен содержать параметр use == old, параметр Patient.name.period должен быть заполнен (start, end) – указывается период действия прежней фамилии
СНИЛС и номер полиса пациента могут проверяться сервисом ОДР на совпадение
контрольной суммы. В случае, если проверка не пройдена, пациент будет добавлен в
сервис, но к некорректному идентификатору будет добавлен параметр Identifier.use == temp. Данная информация должна анализироваться на стороне передающей системы и исправляться в ручном или автоматическом режиме.
Пример запроса и ответ сервиса можно получить по запросу или на тестовой
площадке сервиса ОДР по адресу http://rХХ-rc.zdrav.netrika.ru/exlab_example/, где ХХ – код региона (название примера: addPatient)

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

В подсистеме ОДР должна быть возможность обновить информацию о пациенте.
При обновлении данных должна передаваться полная информация о пациенте, т.е. для корректной работы ИС должна сначала запросить ресурс Patient (операция GET), а потом передать его со всеми параметрами, в том числе и неизменившимися (операция PUT).
Обновление ресурса разрешено только отправителям данного ресурса.
При обновлении пациента в качестве адреса указывается URL в формате
[base]/Prescriptions/api/fhir/Patient/[GUID]?_format=json. GUID пациента в URL должен
соответствовать id, указанному в запросе. В ответе сервис возвращает json с обновленным пациентом и его идентификатором в сервисе ОДР.

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

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

Передача льготы (POST Coverage)

Для регистрации льготы пациента в сервисе ОДР используется POST-запрос ресурса
Coverage. В качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/Coverage?_format=json. В ответе сервис возвращает json с
созданной льготой и её идентификатором в сервисе ОДР.

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

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

№
п/п 		Параметр Тип Кратность Описание
1 identifier identifier 1..* Данные документа о льготе – серия и номер, период действия, тип и др.
1.1 identifier.type CodeableConcept 0..1 Код документа о праве на льготу. Передается в параметре
identifier.type.coding. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.6);    — version — версия справочника;
— code — код значения из справочника
— display – текстовое представление значения
(наименование документа о льготе)
1.2 identifier.value string 0..1 Серия, номер документа о льготе. (UK) Правила передачи:
— серия, номер документа указываются в формате
[Серия]:[Номер].
— в серии и номере запрещены пробелы и спецсимволы
(прямой и обратный слэш, кавычки, %, $ и др.)
— в серии допускаются цифры и буквы русского и латинского
алфавита.
— в номере допускаются только цифры.
— номер документа должен быть уникален в рамках сервиса
В случае отсутствия информации о серии и номере
документа следует передавать уникальный идентификатор
записи о льготе в МИС. Допускается передача в качестве
идентификатора кода категории льготы (type.coding.code)
1.3 identifier.assigner string 1..1 Информация об организации и ИС, передающей льготу.
Вложенные параметры (оба параметра обязательны):
— reference: Ссылка на организацию, передающей льготу в
формате Organization/GUID, где GUID – идентификатор
организации по справочнику 1.2.643.2.69.1.1.1.64 (Auth)
— display: OID передающей ИС (Auth)
2 status code 1..1 Признак активности записи. active – запись активна, может
использоваться, cancelled – запись неактивна, не может
использоваться, draft — запись передана в служебных целях.
Льготы в статусе draft не выгружаются в ФР ЛЛО.
3 type CodeableConcept 1..1 Код категории льготы. Передается в параметре type.coding.
Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии
(1.2.643.5.1.13.13.99.2.541 или 1.2.643.5.1.13.13.99.2.633)
(UK);
— version — версия справочника;
— code — код значения из справочника (UK).
— display – текстовое представление значения (код категории
граждан)
4 relationship CodeableConcept 0..1 Связанная характеристика льготы (код диагноза).
Обязателен для передачи, если указан код категории льготы
«по нозологии». Передается в параметре relationship.coding.
Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии
(1.2.643.5.1.13.13.11.1005);
— version — версия справочника;
— code — код значения из справочника.
— display – текстовое представление значения (код диагноза)
5 beneficiary Reference 1..1 Ссылка на пациента, которому присвоена льгота.
Вложенные параметры (оба параметра обязательны):
— в параметре reference указывается ссылка на существующий ресурс Patient в базе (UK),
— в параметре display указывается фамилия, инициалы имени
и отчества пациента (отчества при наличии). Значение
должно точно совпадать с соответствующим значением в
параметре name.text пациента, к которому относится льгота.
6 period Period 0..1

Период действия документа.
— в параметре start указывается дата начала периода
(обязательный параметр).

— в параметре end – дата окончания периода
(необязательный параметр).
7 payor Reference 0..1

Информация по организации, присвоившей льготу
Вложенные параметры (оба параметра обязательны):
— reference: Ссылка на организацию, присвоившую льготу в
формате Organization/GUID, где GUID – идентификатор
организации по справочнику 1.2.643.2.69.1.1.1.64
— display: Краткое наименование организации
В случае отсутствия информации следует передавать
ссылку на организацию, передающую льготу
8 class BackboneElement 1..1

Сведения о размере льготе (код, значение в процентах)
8.1 class.type CodeableConcept 1..1

Размер льготы (код). Передается в параметре class.type.coding. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии
(1.2.643.5.1.13.13.99.2.605);
— version — версия справочника;
— code — код значения из справочника
— display – наименование размера льготы

8.2 class.value Quantity 1..1

Размер льготы (значение в процентах). Допустимые
значения 0, 50, 90, 100

9 policyHolder Reference 0..1

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

Пример запроса и ответ сервиса можно получить по запросу или на тестовой
площадке сервиса ОДР по адресу http://rХХ-rc.zdrav.netrika.ru/exlab_example/, где ХХ – код региона (название примера: addCoverage)

Обновление льготы (PUT Coverage)

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

При обновлении льготы в качестве адреса указывается URL в формате
[base]/Prescriptions/api/fhir/Coverage/[GUID]?_format=json. В ответе сервис возвращает json с обновленной льготой и её идентификатором в сервисе ОДР.

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

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

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

Для регистрации врача в сервисе ОДР необходимо отправить два запроса
последовательно:

  1. POST [hostname]/Practitioner, в body передать ресурс Practitioner
  2. POST [hostname]/PractitionerRole, в body передать ресурс PractitionerRole

В ответе сервис возвращает json с созданными ресурсами и их идентификаторами в
сервисе ОДР.

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

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

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

№
п/п 		Параметр Тип Кратность Описание
1 identifier identifier 2..2 Идентификатор врача. Указывает идентификатор врача в
передающей системе и СНИЛС (UK). Оба параметра обязательные.
1.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
1.2 identifier.value string 1..1 Значение для идентификатора в МИС или СНИЛС. (UK)
1.3 identifier.assigner Reference 1..1 усл.
(только
при
передаче
ID врача)		 Информация об организации, передающей врача в сервис
(Auth). Вложенные параметры (оба параметра обязательны):
— в параметре reference указывается ссылка на существующий ресурс Organization в формате
Organization/GUID, где GUID – идентификатор организации
по справочнику 1.2.643.2.69.1.1.1.64
— в параметре display указывается OID передающей ИС
2 active boolean 1..1 Признак активности записи. true – запись активна, может
использоваться, false – запись неактивна, не может
использоваться
3 name HumanName 1..1 ФИО врача
3.1 name.family string 1..1 Фамилия
3.2 name.given string 1..2 Имя, Отчество. Сначала указывается Имя
3.3 name.text string 1..1 Фамилия, инициалы имени и отчества врача (отчества при
наличии). Инициалы пишутся с точкой через один пробел.
4 telecom ContactPoint 0..2 Телефон врача. Можно передавать номер рабочего и
мобильного телефона. Вложенные параметры (все параметры обязательны):
— system — тип данных (всегда передается phone).
— use — тип телефона (work – рабочий, mobile — мобильный).
— value — значение номера телефона в формате +7(ХХХ)ХХХХХХХ

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

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

№
п/п 		Параметр Тип Кратность Описание
1 active identifier 1..1 Признак активности записи. true – запись активна, может
использоваться, false – запись неактивна, не может использоваться
2 practitioner Reference 1..1 Ссылка. Соотнесение с врачом. Должна указываться ссылка
на существующий Practitioner в БД (UK)
3 organization Reference 1..1 Ссылка. Соотнесение с организацией, в которой работает
врач. Должна указываться ссылка на существующую в БД
Organization в формате Organization/GUID, где GUID –
идентификатор организации по справочнику
1.2.643.2.69.1.1.1.64 (UK)(Auth)
4 code CodeableConcept 1..1 Код должности врача (UK) Передается в параметре
code.coding. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии
(1.2.643.5.1.13.13.11.1002),
— version —версия справочника
— coding.code — код значения из справочника.
5 specialty CodeableConcept 0..1 Код специальности врача (UK) Передается в параметре
code.coding. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии
(1.2.643.5.1.13.13.11.1066),
— version —версия справочника
— coding.code — код значения из справочника.

Пример запроса и ответ сервиса можно получить по запросу или на тестовой
площадке сервиса ОДР по адресу http://rХХ-rc.zdrav.netrika.ru/exlab_example/, где ХХ – код региона (название примера: addPractitioner, addPractitionerRole)

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

В подсистеме ОДР должна быть возможность обновить информацию о враче. При обновлении данных должна передаваться полная информация о враче, т.е. для более корректной работы ИС должна запросить ресурс Practitioner, PractitionerRole (операция GET), а потом передать его со всеми параметрами, в том числе и неизменившимися (операция PUT). Обновление ресурса разрешено только отправителям данного ресурса.
При обновлении врача в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/PractitionerRole/[GUID] и [base]/Prescriptions/api/fhir/Practitioner/[GUID] В ответе сервис возвращает json с обновленным врачом, квалификацией врача и его идентификатором в сервисе ОДР.

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

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

Передача рецепта (POST Bundle рецепта)

Для передачи рецепта должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:
• Сведения о случае обслуживания;
• Сведения о пациенте и враче;
• Структурированные данные рецепта;
• Электронный документ (PDF и/или CDA)

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

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

№ п/п Ресурс Кратность Операции Возможность использования ссылки на ресурс
1 Encounter 0..1 Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий
2 Patient 0..1 Создание (POST) Может передаваться ресурс или передаваться ссылка на уже существующий ресурс.
3 Coverage 0..1 Создание (POST)
4 Practitioner 0..1 Создание (POST)
5 PractitionerRole 0..1 Создание (POST)
6 MedicationRequest 1..1 Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий
7 Binary 1..6 Создание (POST)

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

При добавлении рецепта в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ОДР.
Json-запрос для передачи рецепта содержит следующие компоненты:
• «resourceType»: «Bundle» — указание, что в запросе передается Bundle,
• «type»: «transaction» — тип Bundle,
• «entry»: [] – массив с данными о передаваемых ресурсах, в котором передается:
— fullUrl ресурса,
— Сам ресурс,

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

POST http://[hostname]/Prescriptions/api/fhir?_format=json
authorization: N3[пробел][Авторизационный токен]
content-type: application/json

{

«resourceType» : «Bundle»,

«type» : «transaction»,

«entry» : [{

«fullUrl» : «urn:uuid:60c9485c-556b-4d67-8b54-35ee9e39083f», /

/GUID ресурса Encounter в Bundle, который используется для связи ресурсов внутри Bundle

«resource» : {

«resourceType» : «MedicationRequest»,

//должны быть перечислены все параметры ресурса Encounter

}

},

{

«fullUrl» : «urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065»,

//GUID ресурса MedicationRequest в Bundle, который используется для связи ресурсов внутри Bundle

«resource» : { «resourceType» : «MedicationRequest», //должны быть перечислены все параметры ресурса MedicationRequest «supportingInformation» : [{ //ссылки на PDF бланк рецепта и его подписи «display» : «application/pdf», «reference» : «urn:uuid:a47a98bf-43b8-4651-8969-39d83d3f3df6» },

{ «display» : «application/x-pkcs7-practitioner»,

«reference» : «urn:uuid:350409e6-9b35-4527-bded-b43cab2a3f7c» },

{

«display» : «application/x-pkcs7-organization»,

«reference» : «urn:uuid:42b596b3-1214-4bbc-9d84-1c9a57d96870» } ] } },

{ «fullUrl» : «urn:uuid:a47a98bf-43b8-4651-8969-39d83d3f3df6»,

«resource» : {

«resourceType» : «Binary»,

«contentType» : «application/pdf»,

«data» : «JVBERi0xLjcNCi…zc3MzANCiUlRU9G» } },

{ «fullUrl» : «urn:uuid:350409e6-9b35-4527-bded-b43cab2a3f7c»,

«resource» : { «resourceType» : «Binary»,

«contentType» : «application/x-pkcs7-practitioner»,

«data» : «MIITdQYJKoZIhvcNAQcCoIITZjCCE2I…Pl/AvVJEfc=» } },

{

«fullUrl» : «urn:uuid:42b596b3-1214-4bbc-9d84-1c9a57d96870», «resource» : { «resourceType» : «Binary»,

«contentType» : «application/x-pkcs7-organization»,

«data» : «MIITdQYJKoZIhvcNAQcCoI…AvVJEfc=»

}
} ]

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

1. Patient

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

2. Coverage

Ресурс Coverage предназначен для передачи информации о льготе пациента.
Список используемых параметров и их описание приведены в документе ранее.

3. Practitioner

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

4. PractitionerRole

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

5. Encounter

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

№ п/п Параметр Тип Кратность Описание
1 identifier Identifier 1..1 Идентификатор случая обслуживания в МИС
1.1 identifier.system uri 1..1 В качестве кодовой системы указывается OID передающей системы[1].
1.2 identifier.value string 1..1 Идентификатор случая обслуживания в МИС.(UK)
1.3 identifier.assigner.display string 1..1 Номер амбулаторной или стационарной карты пациента, в которой оформлен данный случай обслуживания в МИС.
2 status code 1..1 Статус случая обслуживания (справочник FHIR. OID справочника в сервисе Терминологии: 2.16.840.1.113883.4.642.1.247). Передается «in-progress» для открытого случая обслуживания, «finished» для закрытого случая.
3 class Coding 1..1 Класс случая обслуживания (справочник FHIR. OID справочника в сервисе Терминологии: 2.16.840.1.113883.1.11.13955). Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии (2.16.840.1.113883.1.11.13955),
— version — версия справочника в сервисе Терминологии,
— code — код значения из справочника.
Передается EMER для скорой помощи, IMP для ДС при стационаре, AMB для амбулаторного обслуживания, SS для ДС при поликлинике, HH на дому, ACUTE круглосуточный стационар
4 type CodeableConcept 1..1 Тип случая обслуживания (региональный справочник типов случая обслуживания. Передается в параметре type.coding. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии (1.2.643.2.69.1.1.1.35),
— version — версия справочника в сервисе Терминологии,
— code — код значения из справочника.
5 subject reference (Patient) 1..1 Ссылка. Соотнесение с пациентом. Указывается ссылка на существующий в базе ресурс Patient.
6 serviceProvider Reference (Organization) 1..1 Ссылка. Соотнесение с кодом МО (или отделения). Должна указываться ссылка на существующую в БД Organization[2]. (Auth)(UK)

6. MedicationRequest

Ресурс MedicationRequest предназначен для передачи информации о рецепте на ЛП, СПЛП или МИ. Тип рецепта определяется формой бланка рецепта (MedicationRequest.identifier.type) и справочником, используемым при назначении (MedicationRequest.medicationCodeableConcept). Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.

№ п/п Параметр Тип Кратность Описание
1 identifier Identifier 2..2 Идентификаторы рецепта – форма рецепта, серия и номер рецепта (UK), срок действия рецепта
1.1 identifier.system uri 1..1 Пространство имён идентификатора. Указывается: — для формы, серии и номера рецепта OID (1.2.643.5.1.13.2.7.100.11), — для срока действия и периода OID (1.2.643.5.1.13.2.7.100.12)
1.2 identifier.type CodeableConcept 1..1 Тип идентификатора. При передаче формы, серии и номера рецепта в параметре type указывается форма рецепта. При передаче срока действия рецепта в параметре type указывается срок действия рецепта Тип передается в параметре identifier.type.coding. Вложенные параметры (все параметры обязательны):
— system — OID справочника форм (1.2.643.2.69.1.1.1.180) или сроков действия (1.2.643.5.1.13.13.99.2.608) рецепта в сервисе Терминологии;
— version – версия справчоника;           — code — код значения из справочника.
— display – текстовое представление значения
1.3 dentifier.value string 1..1 усл. (только при передаче номера рецепта) Серия, номер рецепта. (UK) Правила передачи:
— серия, номер рецепта указываются в формате [Серия]:[Номер].
— в серии и номере запрещены пробелы и спецсимволы (прямой и обратный слэш, кавычки, %, $ и др.)
— в серии допускаются цифры и буквы русского и латинского алфавита.
— в номере допускаются только цифры.
— серия, номер рецепта должны быть уникальными в рамках сервиса (с учетом формы рецепта)
1.4 identifier.assigner Reference 1..1 усл. (только при передаче номера рецепта) Ссылка на организацию, выписавшую рецепт (Auth). Вложенные параметры (оба параметра обязательны):
— reference — ссылка на существующий ресурс Organization в базе в формате Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64
— display OID передающей ИС
1.5 identifier.period Period 1..1 усл.
(только при передаче срока годности)		 Срок действия рецепта. Вложенные параметры (оба параметра обязательны):
— start — дата начала срока действия рецепта (должен совпадать с MedicationRequest.authoredOn)
— end – дата окончания срока действия рецепта.
2 status code 1..1 Статус рецепта. Всегда передается «active»
3 intent code 1..1 Тип рецепта. Всегда передается «original-order»
4 priority code 1..1 Отметка о срочности. Передается одно из значений: routine (отпуск в плановом порядке), urgent (срочно), stat (немедленно)
5 medicationCodeableConcept CodeableConcept 1..1 Назначенный медикамент. В параметре coding передается информация о выписанном ЛП, МИ, СПЛП. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии;
— version — версия справочника;
— code — код значения из справочника.
— display – текстовое представление значения (наименование, форма выпуска, дозировка и др.)
При выписке ЛП следует использовать справочник OID 1.2.643.5.1.13.13.99.2.611
При выписке СПЛП следует использовать справочник OID 1.2.643.5.1.13.13.99.2.603
При выписке МИ следует использовать справочник OID 1.2.643.5.1.13.13.99.2.604
6 subject Reference 1..1 Ссылка на пациента, которому выписывается рецепт. Вложенные параметры (оба параметра обязательны):
— reference — ссылка на существующий ресурс Patient в базе
— display — фамилия, инициалы имени и отчества пациента (отчества при наличии). Значение должно точно совпадать с соответствующим значением в параметре name.text пациента, которому выписывают рецепт.
7 encounter Reference 0..1 Ссылка на случай обслуживания, в рамках которого выписывается рецепт. Вложенные параметры (оба параметра обязательны):
— reference — ссылка на передаваемый в бандле ресурс Encounter
— display – номер амбулаторной карты пациента
8 supportingInformation Reference 1..6 Ссылка на ресурс Binary (соотнесение с PDF и/или XML документом и УКЭП к ним). Передаются ссылки на PDF и/или XML документ, УКЭП врача и УКЭП МО к ним. Вложенные параметры (все параметры обязательны):
— reference — ссылка на передаваемый в бандле ресурс Binary
— display — тип передаваемого в бандле ресурса Binary
9 requester Reference 1..1 Ссылка на ресурс PractitionerRole, описывающий квалификацию врача, выписавшего рецепт. Вложенные параметры (оба параметра обязательны):
— reference — ссылка на существующий ресурс PractitionerRole в базе
— display — фамилия, инициалы имени и отчества врача (отчества при наличии). Значение должно точно совпадать с соответствующим значением в параметре name.text врача, выписывающего рецепт.
10 reasonCode CodeableConcept 1..1 Диагноз пациента. В параметре coding передается информация о коде МКБ-10 диагноза. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1005),
— version — версия справочника в сервисе Терминологии,
— code — код значения из справочника
— display — клиническая формулировка диагноза
12 insurance Reference 0..1 Ссылка на льготу пациента, по которой выписывается рецепт. Вложенные параметры (оба параметра обязательны):
— reference — ссылка на существующий ресурс Coverage в базе
— display — название документа о льготе
  note Annotaton 0..2 Дополнительная информация по рецепту. Может передаваться:
— информация о проведении врачебной комиссии. Заполняется в случае выписки рецепта на ВК. Передается массивом из двух элементов – в первом указывается дата ВК в формате ГГГГ-ММ-ДД, во втором указывается номер протокола ВК
— информация об отпущенных ЛП, СПЛП или МИ в формате NNNNNNNNN.NN, где NNNNNNNNN.NN стоимость отпущенных препаратов в руб. коп. В случае отсутствия информации данные замещаются нулями, пример: 0.0
— текстовое описание причины изменения статуса рецепта (строкой в произвольном виде)
13 dosageInstruction Dosage 1..1 Способ применения
13.1 dosageInstruction.text string 1..1 Способ применения, текстовая формулировка (SIG)
13.2 dosageInstruction. patientInstruction string 0..1 Указания по применению для пациента
13.3 dosageInstruction.route CodeableConcept 0..1 Способ введения. Вложенные параметры (все параметры обязательны):
— system — OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.11.1468),
— version — версия справочника в сервисе Терминологии,
— code — код значения из справочника
— display — текстовое представление значения
13.4 dosageInstruction.timing Timing 0..1 Интервал приема. Передается в параметре dosageInstruction.timing.repeat Вложенные параметры (все параметры обязательны):
— frequency — количество приемов за интервал,
— period — длительность интервала,
— periodUnit — код единицы измерения для интервала (h – час, d – день, wk — неделя, mo — месяц)
13.5 dosageInstruction.doseAndRate Element 0..1 Разовая доза. Передается в параметре dosageInstruction.doseAndRate.doseQuantity Вложенные параметры (все параметры обязательны):
— value — количество ЛП, СПЛП или МИ,
— code — код единицы измерения для ЛП, СПЛП или МИ по справочнику 1.2.643.5.1.13.13.11.1358
— unit — наименование единицы измерения для ЛП, СПЛП или МИ
14 dispenseRequest BackboneElement 1..1 Количество, срок действия
14.1.
 dispenseRequest.quantity SimpleQuantity 1..1 Количество выписанного ЛП, СПЛП или МИ. Вложенные параметры (все параметры обязательны):
— value — количество выписанного ЛП, СПЛП или МИ
— code – код единицы измерения для ЛП, СПЛП или МИ по справочнику 1.2.643.5.1.13.13.11.1358
— unit — наименование единицы измерения
14.2 dispenseRequest.expectedSupplyDuration Duration 0..1 Продолжительность приема ЛП, СПЛП или МИ (необязательный параметр). Вложенные параметры (все параметры обязательны):
— value — количество дней / месяцев приема
— code – единица измерения, 01 – в днях, 02 – в месяцах
— unit — наименование единицы измерения

7. Binary

В Bundle для передачи бланка рецепта в формате PDF или XML и УКЭП для данного бланка используется ресурс Binary. Формат передаваемых данных определяется настройками сервиса.
В качестве PDF-документа должен передаваться пригодный для просмотра и печати бланк рецепта, соответствующий передаваемым структурированным данным. Передача пустого PDF документа или документа, не содержащего требуемых данных, не допускается. Текстовая часть должна включаться в документ формата PDF/A-1 в виде текстовых данных. Вставка текста в документ в виде изображения не допускается.

Файл документа в электронном виде должен иметь формат 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
В качестве подписи должна передаваться УКЭП в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012
Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.

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

Передача отпуска (POST Bundle отпуска)

Для передачи отпуска должен использоваться Bundle типа транзакция. В Bundle должна передаваться следующая информация:
• Сведения об отпуске;
• Сведения о враче;
• Структурированные данные отпуска;
• Электронный документ (PDF и/или CDA)

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

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

№ п/п Ресурс Кратность Операции Возможность использования ссылки на ресурс
1 Practitioner 0..1 Создание (POST) Может передаваться ресурс или передаваться ссылка на уже существующий ресурс
2 PractitionerRole 0..1 Создание (POST)
3 MedicationDispense 1..1 Создание (POST) Всегда должен передаваться ресурс. Не может передаваться ссылка на уже существующий.
4 Binary 1..6 Создание (POST)

Структура запроса Bundle отпуска

При добавлении отпуска в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/. В ответе сервис возвращает сохраненные ресурсы из переданного Bundle со внутренними идентификаторами сервиса ОДР.
Json-запрос для передачи рецепта содержит следующие компоненты:
• «resourceType»: «Bundle» — указание, что в запросе передается Bundle,
• «type»: «transaction» — тип Bundle,
• «entry»: [] – массив с данными о передаваемых ресурсах, в котором передается:
o fullUrl ресурса,
o Сам ресурс,
Пример запроса и ответ сервиса можно получить по запросу или на тестовой площадке сервиса ОДР по адресу http://rХХ-rc.zdrav.netrika.ru/exlab_example/ , где ХХ – код региона (название примера: addBundle_medical_dispense

POST http://[hostname]/Prescriptions/api/fhir?_format=json

authorization: N3[пробел][Авторизационный токен]

content-type: application/json

{ «resourceType» : «Bundle»,

«type» : «transaction»,

«entry» :

{ «resource» : { «resourceType» : » MedicationDispense»,

//должны быть перечислены все параметры ресурса MedicationDispense «supportingInformation» : [{ //ссылки на CDA или PDF документ и его подписи

«display» : «application/pdf»,

«reference» : «urn:uuid:a47a98bf-43b8-4651-8969-39d83d3f3df6» },

{ «display» : «application/x-pkcs7-practitioner»,

«reference» : «urn:uuid:350409e6-9b35-4527-bded-b43cab2a3f7c» },

{ «display» : «application/x-pkcs7-organization»,

«reference» : «urn:uuid:42b596b3-1214-4bbc-9d84-1c9a57d96870» } ] } },

{ «fullUrl» : «urn:uuid:a47a98bf-43b8-4651-8969-39d83d3f3df6»,

«resource» : { «resourceType» : «Binary»,

«contentType» : «application/pdf», «data» : «JVBERi0xLjcNCi…zc3MzANCiUlRU9G» } },

{ «fullUrl» : «urn:uuid:350409e6-9b35-4527-bded-b43cab2a3f7c»,

«resource» : { «resourceType» : «Binary»,

«contentType» : «application/x-pkcs7-practitioner»,

«data» : «MIITdQYJKoZIhvcNAQcCoIITZjCCE2I…Pl/AvVJEfc=» } },

{ «fullUrl» : «urn:uuid:42b596b3-1214-4bbc-9d84-1c9a57d96870»,

«resource» : { «resourceType» : «Binary»,

«contentType» : «application/x-pkcs7-organization»,

«data» : «MIITdQYJKoZIhvcNAQcCoI…AvVJEfc=» } } ]

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

1. Practitioner

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

2. PractitionerRole

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

3. MedicationDispense

Ресурс MedicationDispense предназначен для передачи информации об отпуске ЛП, СПЛП или МИ. Передача информации об отпуске разрешена только для рецептов в статусе “on-hold” или “active”. Успешная передача информации об отпуске меняет статус рецепта на “completed”
Перечень параметров и их описание представлены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.

№ п/п Параметр Тип Кратность Описание
1 identifier Identifier 1..1 Идентификатор документа отпуска рецепта
1.1 identifier.system uri 1..1 Пространство имён идентификатора. Всегда указывается urn:oid:1.2.643.5.1.13.2.7.100.5
1.2 identifier.value string 1..1 Номер документа об отпуске (уникальный в рамках системы). (UK)
1.3
 identifier.assigner Reference 1..1 Ссылка на организацию, отпустившую рецепт (Auth)
· В параметре reference указывается ссылка на существующий ресурс Organization в базе в формате Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64 (UK)
· В параметре display указывается OID передающей системы (UK)
· Все параметры обязательные (1..1)
2 status code 1..1 Статус документа. Передается «completed» для отпущенных рецептов, «declined» для рецептов с отказом в отпуске
3 statusReasonCodeableConcept statusReasonCodeableConcept 0..1 усл. Причина отказа в отпуске рецепта (обязательна при status == declined) или информация об отложенном обслуживании (возможна при status == completed).
В параметре coding передаются параметры, в которых указываются:
· system — OID справочника в сервисе Терминологии (1.2.643.5.1.13.13.99.2.654 для указания причины отказа в отпуске рецепта, 1.2.643.5.1.13.13.99.2.637 для указания информации об отложенном обслуживании);
· version — версия справочника;
· code — код значения из справочника.
· display – текстовое представление значения (наименование причины отказа в отпуске или информации об отложенном обслуживаниии)
Все параметры обязательные (1..1)
4 medicationCodeableConcept CodeableConcept 1..1 Отпущенные ЛП, СПЛП или МИ. Обязательно при status == completed.
В параметре coding передаются параметры, в которых указываются:
· system — OID справочника в сервисе Терминологии (ЛП (1.2.643.5.1.13.13.99.2.540), СПЛП (1.2.643.5.1.13.13.99.2.603) или МИ (1.2.643.5.1.13.13.99.2.604));
· version — версия справочника;
· code — код значения из справочника.
ВАЖНО!!! При передаче значений по справочнику 1.2.643.5.1.13.13.99.2.540 передавать необходимо значения поля «Код КЛП» справочника ФНСИ, а не поля «Код».
При валидации значения в справочнике сервис возвращает ошибку вида «Значение ХХХ’ отсутствует в справочнике 1.2.643.2.69.1.1.1.540.» – следует иметь ввиду, что в ошибке указывается OID справочника перекодировки, фактически значение валидируется по полю «Код КЛП» справочника 1.2.643.5.1.13.13.99.2.540
· display – текстовое представление значения (наименование препарата, форма выпуска, дозировка)
Все параметры обязательные (1..1)
5 authorizingPrescription Reference 1..1 Ссылка на рецепт, по которому выданы ЛП, СПЛП или МИ
В параметре reference указывается ссылка на существующий ресурс MedicationRequest в базе ИЛИ
В параметре display указывается серия и номер рецепта (формат “серия:номер”), по которому оформляется отпуск, если в сервисе отсутствует существующий ресурс MedicationRequest (передача отпуска без рецепта должна быть включена в настройках сервиса)
6 subject Reference 1..1 Ссылка на пациента, которому был выписан рецепт. Вложенные параметры (оба параметра обязательны):
— reference — ссылка на ресурс Patient, указанный в связанном рецепте
— display — фамилия, инициалы имени и отчества пациента (отчества при наличии). Значение должно точно совпадать с соответствующим значением в параметре name.text пациента, которому выписывают рецепт.
7 whenHandedOver dateTime 1..1 Дата отпуска
8 performer.actor Reference 1..1 Ссылка на сотрудника, отпустившего ЛП, СПЛП или МИ по рецепту
· В параметре reference указывается ссылка на существующий ресурс PractitionerRole в базе
· В параметре display указывается фамилия, инициалы имени и отчества сотрудника (отчества при наличии)
Все параметры обязательные (1..1)
9 quantity SimpleQuantity 1..1 Количество и стоимость отпущенного ЛП, СПЛП или МИ
o В параметре value указывается количество отпущенных потребительских упаковок ЛП, СПЛП или МИ (целое число)
o В параметре code – код единицы измерения для ЛП, СПЛП или МИ по справочнику 1.2.643.5.1.13.13.11.1358
o В параметре unit указывается наименование единицы измерения
o В параметре extension.valueMoney.value указывается стоимость в рублях за единицу отпущенной потребительской упаковки медицинской продукции
10 supportingInformation Reference 0..6 Ссылка на ресурс Binary (соотнесение с PDF и/или XML документом и УКЭП к ним). Передаются ссылки на PDF и/или XML документ, УКЭП врача и УКЭП МО к ним. Вложенные параметры (все параметры обязательны):
— reference — ссылка на передаваемый в бандле ресурс Binary
— display — тип передаваемого в бандле ресурса Binary

4. Binary

В Bundle для передачи документа в формате PDF или XML и УКЭП для данного бланка используется ресурс Binary. Формат передаваемых данных определяется настройками сервиса.

В качестве PDF-документа должен передаваться пригодный для просмотра и печати бланк отпуска, соответствующий передаваемым структурированным данным. Передача пустого PDF документа или документа, не содержащего требуемых данных, не допускается. Текстовая часть должна включаться в документ формата PDF/A-1 в виде текстовых данных. Вставка текста в документ в виде изображения не допускается.
Файл документа в электронном виде должен иметь формат 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
В качестве подписи должна передаваться УКЭП в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012
Список используемых параметров и их описание приведены в таблице ниже. Параметры, которые не используются в информационном обмене, в таблице не указаны.

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

Передача информации об отпуске ЛП, СПЛП или МИ (POST MedicationDispense)

В случае, если при передаче информации об отпуске не передаются связанные ресурсы (врач, вложения) для регистрации информации об отпуске ЛП, СПЛП или МИ в сервисе ОДР используется POST-запрос ресурса MedicationDispense. В качестве адресауказывается URL в формате [base]/Prescriptions/api/fhir/MedicationDispense?_format=json. В ответе сервис возвращает json с информацией об отпуске ЛС и МИ и её идентификатором в сервисе ОДР.
Список используемых параметров и их описание приведены в документе ранее.

Передача УКЭП

Для обеспечения юридической значимости совместно с рецептом должны передаваться две электронные подписи – УКЭП врача и УКЭП МО. УКЭП должна передаваться в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012.
Файлы PDF или XML и соответствующие им УКЭП в формате base64binary в ресурсах Binary. Ссылки на эти ресурсы передаются в MedicationRequest.
Тип содержимого в ресурсе передается через параметр ContentType: application/pdf для бланка рецепта в формате PDF, application/xml для рецепта в формате XML, application/x-pkcs7-practitioner для УКЭП врача и application/x-pkcs7-organization для УКЭП МО

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

Передача УКЭП для структурированных данных

Описание

Особенность реализации сервиса такова, что в БД сервиса хранятся данные, в которых изменены атрибуты – параметр fullUrl заменяется на ссылку на ресурс. В рядеслучаев необходимо иметь в сервисе юридически значимые структурированные данные, переданные МИС с УКЭП. Данный механизм реализуется следующим образом:
1. Особым образом подготовленный JSON с данными подписывается УКЭП как текстовый файл и передается в сервис вместе с УКЭП. Передаваемая УКЭП проверяется:
• на соответствие ОГРН МО, указанного в файле УКЭП, и ОГРН МО, указанный в справочнике МО для МО, передающей ресурс или бандл
• на соответствие передаваемым структурированным данным
2. Если проверки не выполняются, сервис возвращает соответствующие ошибки
3. Если проверки выполняются, в БД сервиса сохраняются УКЭП и переданный бандл в неизменном виде
4. В случае необходимости проверки хранящихся в сервисе данных необходимо:
• штатными средствами ОДР запрашиваются и фиксируются требуемые данные
• средствами администрирования БД получается исходный бандл и УКЭП для него
• средствами проверки УКЭП (КриптоПро и т.п.) проверяется соответствие исходного бандла и хранящейся с ним УКЭП
• средствами просмотра JSON проверяется соответствие данных, запрошенных из ОДР штатными средствами, и исходного бандла
Если исходный бандл прошел проверку УКЭП и данные, запрошенные из ОДР штатными средствами, и исходный бандл соответствуют друг другу, то структурированные данные в сервисе признаются юридически значимыми.

Техническая реализация

Совместно с рецептом должна передаваться УКЭП МО. УКЭП должна передаваться в формате CMS (Cryptographic Message Syntax). УКЭП должны формироваться с использованием алгоритмов ГОСТ Р 34.10-2012 и передаваться в формате base64binary в HTTP заголовке (header) signature. Пример передачи:

signature: MIIThvcNAQcCoIITZjCCE2ICAQExDjAMBggqhQMHAQECAgUAMAsGCSqGSIb3DQEHAa…
 
Для возможности валидации передаваемых данных на соответствие переданной с ними УКЭП JSON c данными (ресурс, бандл) должны быть минимизированы (JSONmin). JSON не должен содержать символы перевода строк, возврата каретки, пробелы, символы табуляции и другие символы. JSON должен быть корректен по структуре (валидный JSON). Пример передачи:
 
{«resourceType»:»Bundle»,»type»:»transaction»,»meta»:{«profile»:[«Struct…

Отмена рецепта ($cancelprescription)

Передача информации об отмене рецепта со стороны МИС (отметка «Рецепт испорчен») осуществляется с помощью дополнительной операции (Custom Operation) cancelprescription (POST). Отменить можно только рецепт в статусе «active». Отмена рецепта разрешена только для организации – отправителя рецепта.
При отмене рецепта используется POST запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/$cancelprescription?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с обновленным ресурсом.

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

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

№ п/п Имя параметра Описание Тип Кратность
1 Organization Ссылка на организацию, выписавшую рецепт, в формате Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64 string 1..1
2 PrescriptionID Ссылка на рецепт вида MedicationRequest/ID string 1..1
3 Note Текстовое описание причины отмены рецепта string 0..1

Изменение статуса рецепта ($updatestatus)

Передача информации об изменении статуса рецепта со стороны сервиса СОМР (отметки «Рецепт отклонен», «Рецепт поставлен на отложенное обслуживание», «Рецепт отоварен») осуществляется с помощью дополнительной операции (Custom Operation) updatestatus (POST).
При изменении статуса рецепта используется POST запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/$updatestatus?_format=json, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с обновленным ресурсом.

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

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

№ п/п Имя параметра Описание Тип Кратность
1 Status Статус рецепта после обновления * string 1..1
2 PrescriptionID Ссылка на рецепт вида MedicationRequest/ID string 1..1
3 Note Текстовое описание причины изменения статуса рецепта или информация об отпущенных ЛП, СПЛП или МИ string 1..1

* Разрешено передавать только определенные статусы: on-hold (поставлен на отложенное обслуживание), cancelled (отменен), completed (выполнен)
При передаче статуса completed в Note необходимо передавать информацию об отпущенных ЛП, СПЛП или МИ в формате NNNNNNNNN.NN, где NNNNNNNNN.NN стоимость отпущенных препаратов в руб. коп. В случае отсутствия информации данные замещаются нулями, пример: 0.0
Текстовое описание причины изменения статуса рецепта передается строкой в произвольном виде.

Поиск врача и пациента по СНИЛС (_search)

Поиск врача, пациента в БД для получения идентификатора осуществляется с помощью стандартного поиска FHIR (POST или GET).
При поиске методом POST используется POST запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/Patient/_search для поиска пациента и [base]/Prescriptions/api/fhir/Practitioner/_search для поиска врача, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с найденными ресурсами.

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

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

№ п/п Имя параметра Описание Тип Кратность
1 identifier СНИЛС врача или пациента string 1..1

Выходным параметром является Bundle, содержащий найденные ресурсы Patient или Practitioner.

При поиске методом GET используется GET запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/Patient?identifier=1.2.643.2.69.1.1.1.6.223|(номер СНИЛС) для поиска пациента и [base]/Prescriptions/api/fhir/Practitioner/?identifier=1.2.643.2.69.1.1.1.6.223|(номер СНИЛС) для поиска врача, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с найденными ресурсами.

Поиск квалификации врача по идентификатору врача (_search)

Поиск квалификации врача в БД для получения идентификатора осуществляется с помощью стандартного поиска FHIR (POST или GET).

При поиске методом POST используется POST запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/PractitionerRole/_search, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с найденными ресурсами.

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

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

№ п/п Имя параметра Описание Тип Кратность
1 practitioner Ссылка на врача в БД string 1..1

Выходным параметром является Bundle, содержащий найденные ресурсы Patient или Practitioner.

При поиске методом GET используется GET запрос, в качестве адреса указывается URL [base]/Prescriptions/api/fhir/PractitionerRole/?practitioner=(Ссылка на врача в БД) для поиска врача, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с найденными ресурсами.

Поиск льгот пациента (_search)

Поиск льгот, имеющихся у пациента, осуществляется с помощью стандартного поиска FHIR (POST или GET).
При поиске методом POST используется POST запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/Coverage/_search, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с найденными ресурсами.

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

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

№ п/п Имя параметра Описание Тип Кратность
1 beneficiary Ссылка на пациента в БД string 1..1

Выходным параметром является Bundle, содержащий найденные ресурсы Coverage.

При поиске методом GET используется GET запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/Coverage?beneficiary=(Ссылка на пациента в БД). В ответе сервис возвращает json с найденными ресурсами Coverage.

Поиск рецептов в сервисе по дате и МО (_search)

Поиск рецептов в сервисе по дате и МО осуществляется с помощью стандартного поиска FHIR (POST).
При поиске используется POST запрос, в качестве адреса указывается URL в формате [base]/Prescriptions/api/fhir/MedicationRequest/_search, в теле запроса передаются параметры запроса. В ответе сервис возвращает json с найденными ресурсами.

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

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

№ п/п Имя параметра Описание Тип Кратность
1 _count Количество результатов в ответе для постраничного вывода результатов string 1..1
2 _page номер страницы в ответе для постраничного вывода результатов string 1..1
3 status Статус рецепта string 0..1
4 _lastUpdated Дата последнего изменения ресурса string 2..2*
5 authoredon Дата выписки рецепта для MedicationRequest string 2..2*
6 _mo Ссылка на организацию, выписавшую рецепт в формате Organization/GUID, где GUID – идентификатор организации по справочнику 1.2.643.2.69.1.1.1.64 reference 1..1

* Поиск осуществляется по одной из дат — _lastUpdated (дата последнего изменения, для любых рецептов), authoredon (дата выписки для MedicationRequest). Всегда передается два параметра – дата начала диапазона поиска в формате geYYYY-MM-DD и дата окончания диапазона поиска в формате leYYYY-MM-DD
Выходным параметром является Bundle, содержащий найденные ресурсы MedicationRequest.

Запрос рецептов из сервиса по номеру (_search)

Поиск рецептов в сервисе осуществляется с помощью стандартного поиска FHIR (GET).
При поиске используется GET запрос, в качестве адреса указывается URL в формате [base]/ /Prescriptions/api/fhir/MedicationRequest/?identifier=32:000003, где 32:000003 серия и номер рецепта. В ответе сервис возвращает json с найденными ресурсами.

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

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

Выгрузка рецептов и отпуска в РЭМД

Для возможности передачи рецептов и отпуска в федеральный сервис РЭМД (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
— на соответствие передаваемому документу.
В случае невыполнения указанных условий сервис возвращает соответствующие ошибки. Если результат принят сервисом – он считается прошедшим базовые проверки и пригодным для выгрузки в РЭМД.

Непосредственно выгрузка в федеральные сервисы (СЭМД, РЭМД) осуществляется отдельными сервисами, не являющимися частью ОДР. При передаче сведений в федеральные сервисы дополнительно проверяется совпадение передаваемой организации, должности врача, СНИЛС врача на соответствие данным ФРМР, а также выполняется форматно-логический контроль. Все вопросы по выгрузке результатов в
федеральные сервисы, включая получение логов, следует адресовать в подразделение, ответственное за выгрузку.

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

Для корректной работы подсистемы ОДР смежные инфосистемы должны поддерживать методы сервиса Терминологии. Должны поддерживаться следующие методы:
• Запрос справочника
• Запрос списка версий справочника
• Запрос значений справочника ($expand)
• Поиск значения в справочнике ($lookup)
• Валидация значения в справочнике ($validate-code)

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

Получение информации о справочнике осуществляется с помощью 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»
}
]
}