Описание сервиса ОДР
Общие положения
- Настоящее описание интеграционных профилей модуля «Обмена данными рецептов» (далее – Описание) определяет механизмы информационного взаимодействия медицинских информационных систем (далее – МИС), систем обеспечения медицинскими ресурсами (далее – СОМР) и сервиса «Обмен данными рецептами» (далее – сервис ОДР), входящих в состав Регионального сегмента Единой
государственной системы в сфере здравоохранения. - Описание предназначено для организаций-разработчиков, осуществляющих сопровождение эксплуатируемых информационных систем и разработку новых систем
- В рамках информационного взаимодействия сервис ОДР поддерживает получение следующих сведений от сторонних информационных систем:
• Информация о пациенте (идентификатор в ИС, пол и дата рождения, ФИО и т.д.).
• Информация о враче (идентификатор в ИС, ФИО и т.д.).
• Информация о льготе.
• Информация о рецепте. - Документ содержит описание методов сервиса ОДР, которые должны поддерживать сторонние информационные системы для обеспечения автоматизированного информационного взаимодействия.
Определения, обозначения и сокращения
Сокращение, обозначение | Определение |
МИС | Медицинская информационная система |
СОМР | Система обеспечения медицинскими ресурсами |
МО | Медицинская организация |
ДУЛ | Документ, удостоверяющий личность пациента |
ЕНП | Единый номер полиса ОМС нового образца |
ОМС | Обязательное медицинское страхование |
СНИЛС | Страховой номер индивидуального лицевого счёта |
УКЭП | Усиленная квалифицированная электронная подпись |
ЛП | Лекарственный препарат |
СПЛП | Специализированный препарат лечебного питания |
МИ | Медицинское изделие |
При описании ресурсов и используемых параметров используется понятие
«Кратность». Кратность — это нижняя и верхняя граница того, сколько раз элементу
разрешено появляться в ресурсе (см. описание параметров), или ресурсу в Bundle (см.
структуру Bundle), при этом используются следующие обозначения:
0..1 — минимальное количество элементов ноль (параметр может не
передаваться), максимальное один. Интерпретируется как необязательный параметр;
0..* — минимальное количество элементов ноль (параметр может не
передаваться), максимальное количество элементов не ограничено. Интерпретируется как
необязательный параметр;
1..1 — минимальное количество элементов один, максимальное один. Всегда
передается один элемент. Интерпретируется как обязательный параметр;
1..2 — минимальное количество элементов один, максимальное два.
Интерпретируется как обязательный параметр;
2..2 — минимальное количество элементов два, максимальное два. Всегда
передается два элемента. Интерпретируется как обязательный параметр;
1..* – минимальное количество элементов один, максимальное количество
элементов не ограничено. Интерпретируется как обязательный параметр.
Описание решения
Краткое описание процесса
Процесс проведения
ОДР — сервис Обмена Данными Рецептов — предназначен для учета лекарственных
препаратов (ЛП), специализированных продуктов лечебного питания (СПЛП) и
медицинских изделий (МИ), назначенных (выписанных) пациенту.
Назначения могут быть оформлены:
• при амбулаторном лечении пациента — с использованием медицинского
документа «Рецепт»
• при стационарном лечении пациента — с использованием медицинского
документа «Лист назначений»
В текущей версии ПО поддерживается информационное взаимодействие при
работе с рецептами. Листы назначения не поддерживаются.
Общая схема информационного взаимодействия в каждом конкретном случае
определяется на этапе технического проектирования. Фактические роли и права
участников информационного взаимодействия определяются предоставленными им
правами доступа).
Поставщиком документов о назначении является медицинская информационная
система (МИС, английская интерпретация Hospital information system, HIS)
Хранилищем документов о назначении является сервис обмена данными рецептов
(ОДР, английская интерпретация Prescription repository, PR)
Потребителем документов о назначении является система обеспечения
медицинскими ресурсами (СОМР, английская интерпретация Pharmacy dispensing
information system, PDIS)
В зависимости от требований региона к сервису, могут быть реализованы различные
схемы взаимодействия информационных систем с сервисом. МИС и СОМР могут изменять статусы рецепта, проставляя отметки о порче рецепта, о постановке на отложенное обслуживание, об отпуске рецепта. Сервис ОДР может выгружать информацию в ФР ЛЛО
Описание взаимодействия с сервисом
Сервис ОДР предназначен для ведения, хранения, поиска и выдачи сведений по
рецептам в рамках региона. Сервис обеспечивает:
- Учет информации о пациентах, которым назначено лечение.
- Учет информации о медперсонале
- Централизованный учет рецептов и отпуска по рецепту.
- Предоставление информации по выписанным рецептам и отпускам по рецепту.
Обмен данными между МИС МО, СОМР и сервисом ОДР осуществляется в рамках
следующих сценариев:
- Добавление пациента, льготы, врача в ОДР. Данные из МИС, СОМР передается в сервисОДР.
- Добавление рецепта и данных случая обслуживания в ОДР. Рецепт передается из МИС или СОМР. В сервис ОДР должны передаваться только подписанные рецепты.
- Запрос и обновление статуса рецепта. МИС и СОМР могут запрашивать и обновлять
статус рецепта (испорчен или отклонен, отложен, отоварен) - Добавление отпуска по рецепту в ОДР. Отпуск по рецепту передается из МИС или СОМР. В сервис ОДР должны передаваться только подписанные рецепты.
- Предоставление информации по рецептам и отпускам. Сторонние системы могут
запрашивать информацию по рецептам и отпускам.
Описание протокола взаимодействия
Общая информация о сервисе
Информационный обмен осуществляется в соответствии со стандартом 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);
- передача бандла рецепта;
- запрос ресурсов
Требования к передаче данных
Для передачи данных в сервис ОДР необходимо передавать в заголовке сообщения
авторизационный токен в формате:
Авторизационный токен выдается разработчику МИС администратором
интеграционной платформы. Авторизационный токен должен соответствовать
идентификатору информационной системы, указанному в идентификаторе рецепта.
Авторизационный токен выдается на каждый экземпляр (инсталляцию) МИС отдельно.
Для передачи данных в сервис необходимо передавать в заголовке сообщения
заголовок вида 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, осуществляется в следующей структуре:
{
«system»: «urn:oid:[OID справочника в сервисе Терминологии]»,
«version»: «[версия справочника]»,
«code»: «[код значения]»
}
]
При передаче параметров, использующих значения внутренних справочников FHIR,
указывается только код значения (справочники стандарта FHIR также опубликованы
в сервисе Терминологии)
Особенности использования справочников: при передаче любого значения с
использованием справочника необходимо передавать в том числе используемую версию справочника. Допускается передача значений только по актуальной версии справочника.
При валидации значений сервисом значения, передаваемые без указания версии
справочника или с указанием неактуальной версии, не проходят валидацию и не
принимаются сервисом. Передача значений, отсутствующих в актуальной версии
справочника, невозможна.
Примеры справочников для региона приводятся на тестовой площадке сервиса
Терминология по адресу http://rХХ-rc.zdrav.netrika.ru/nsiui , где ХХ – код региона
Методы сервиса
Сервис ОДР поддерживает следующие методы:
- Передача пациента (POST Patient)
- Обновление пациента (PUT Patient)
- Передача льготы (POST Coverage)
- Обновление льготы (POST Coverage)
- Передача врача (POST Practitioner)
- Обновление врача (PUT Practitioner)
- Передача рецепта (POST Bundle рецепта)
- Запрос ресурсов (GET resource)
- Отмена рецепта со стороны МИС ($cancelprescription)
- . Изменение статуса рецепта со стороны СОМР ($updatestatus)
- Поиск врача и пациента по СНИЛС
- Поиск льгот пациента
Примеры использования методов для региона приводятся на тестовой площадке
сервиса ОДР по адресу 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 |
Период действия документа. — в параметре end – дата окончания периода |
7 | payor | Reference | 0..1 |
Информация по организации, присвоившей льготу |
8 | class | BackboneElement | 1..1 |
Сведения о размере льготе (код, значение в процентах) |
8.1 | class.type | CodeableConcept | 1..1 |
Размер льготы (код). Передается в параметре class.type.coding. Вложенные параметры (все параметры обязательны): |
8.2 | class.value | Quantity | 1..1 |
Размер льготы (значение в процентах). Допустимые |
9 | policyHolder | Reference | 0..1 |
Ссылка на организацию, передающую льготу в сервис в |
Пример запроса и ответ сервиса можно получить по запросу или на тестовой
площадке сервиса ОДР по адресу 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)
Для регистрации врача в сервисе ОДР необходимо отправить два запроса
последовательно:
- POST [hostname]/Practitioner, в body передать ресурс Practitioner
- 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. Пример передачи:
Отмена рецепта ($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. Метод возвращает метаинформацию о справочнике и пары код-значение.
Пример запроса:
Поиск значения в справочнике ($lookup)
Метод предназначен для получения дополнительной информации о значении справочника по коду этого значения. Поиск заданного значения в справочнике осуществляется с помощью POST-запроса по URL в формате [base]/ValueSet/$lookup. Метод возвращает json с детализированной информацией о значении, которое соответствует коду значения из запроса.
Пример запроса:
Валидация значения в справочнике ($validate-code)
Метод предназначен для проверки: принадлежит ли код значения из запроса указанному справочнику. Валидация значения в справочнике осуществляется с помощью POST-запроса по URL в формате [base]/ValueSet/$validate-code. Метод возвращает результат проверки значения справочника.
Пример запроса: