Аннотация

Cервис интеграционной платформы N3 «Сервис обмена данными рецептами» (Сервис ОДР) обеспечивает механизмы взаимодействия и обмена медицинскими данными между различными информационными системами при оказании медицинской помощи населению.
По ссылке http://test.zdrav.netrika.ru/exlab_test/ можно ознакомиться с размещенным на тестовой площадке полным описанием API в формате PDF и базовой цепочкой запросов сервиса

При разработке интеграции в рамках какого-либо региона следует пользоваться региональной тестовой площадкой конкретного региона. Адрес и реквизиты доступа к региональной тестовой площадке предоставляются по запросу в службу технической поддержки компании (ОТРС). Доступ к службе технической поддержки осуществляется по ссылке https://otrs.n3med.ru/otrs/customer.pl#Signup

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

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

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

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

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

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

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

Назначения могут быть оформлены:

• при амбулаторном лечении пациента - с использованием медицинского документа "Рецепт" 
• при стационарном лечении пациента - с использованием медицинского документа "Лист назначений" 

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

Поставщиком документов о назначении является медицинская информационная система (МИС, английская интерпретация  Hospital information system, HIS)

Хранилищем документов о назначении является сервис обмена данными рецептов (ОДР, английская интерпретация Prescription repository, PR)

Потребителем документов о назначении является система обеспечения медицинскими ресурсами (СОМР, английская интерпретация Pharmacy dispensing information system, PDIS)

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

Схема 1. С использованием централизованного регистра пациентов и врачей, ведущегося на стороне СОМР

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

• СОМР загружает в сервис ОДР методом POST данные по пациентам, льготам, врачам (ресурсы Patient, Coverage, Practitioner) и в дальнейшем поддерживает их актуальность методом PUT 
• МИС запрашивает из сервиса ОДР данные по пациентам и врачам методом _search 
• МИС или СОМР (в зависимости от региональных требований) передает в сервис ОДР методом POST Bundle пакет данных рецепта, состоящий из данных случая обслуживания (ресурс Encounter), структурированных данных рецепта (ресурс MedicationRequest), печатной формы бланка рецепта и УКЭП к нему (ресурсы Binary), а также данные по пациентам, льготам и врачам (ресурсы Patient, Coverage, Practitioner, PractitionerRole). Данные по пациентам и врачам (ресурсы Patient,  Coverage, Practitioner, PractitionerRole) могут быть переданы заранее методом POST соответствующих ресурсов. Пакет структурированных данных (Bundle рецепта) также может быть подписан УКЭП. 
• ОДР хранит полученный Bundle рецепта as is, а также раскладывает его по ресурсам в БД для возможности получения необходимой информации. 
• МИС и СОМР могут изменять статусы рецепта, проставляя отметки о порче рецепта, о постановке на отложенное обслуживание, об отоваривании рецепта. 
• МИС может получать статус рецепта для отображения его врачу

Схема 2. С использованием централизованного регистра пациентов и врачей, ведущегося на стороне СОМР, и децентрализованной передачей пациентов и врачей МИС

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

• МИС передает в сервис ОДР методом POST Bundle пакет данных рецепта, состоящий из данных случая обслуживания (ресурс Encounter), структурированных данных рецепта (ресурс MedicationRequest), печатной формы бланка рецепта и УКЭП к нему (ресурсы Binary), а также данные по пациентам и врачам (ресурсы Patient, Practitioner, PractitionerRole). Данные по пациентам и врачам (ресурсы Patient,  Practitioner, PractitionerRole) могут быть переданы заранее методом POST соответствующих ресурсов. Пакет структурированных данных (Bundle рецепта) также может быть подписан УКЭП. 
• ОДР хранит полученный Bundle рецепта as is, а также раскладывает его по ресурсам в БД для возможности получения необходимой информации. 
• МИС и СОМР могут изменять статусы рецепта, проставляя отметки о порче рецепта, о постановке на отложенное обслуживание, об отоваривании рецепта. 
• МИС может получать статус рецепта для отображения его врачу

Схема 3. С децентрализованной передачей пациентов и врачей МИС

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

• МИС или СОМР передает в сервис ОДР методом POST Bundle пакет данных рецепта, состоящий из данных случая обслуживания (ресурс Encounter), структурированных данных рецепта (ресурс MedicationRequest), печатной формы бланка рецепта и УКЭП к нему (ресурсы Binary), а также данные по пациентам, льготам и врачам (ресурсы Patient,  Coverage, Practitioner, PractitionerRole). Данные по пациентам, льготам и врачам (ресурсы Patient, Coverage, Practitioner, PractitionerRole) могут быть переданы заранее методом POST соответствующих ресурсов. Пакет структурированных данных (Bundle рецепта) также может быть подписан УКЭП. 
• ОДР хранит полученный Bundle рецепта as is, а также раскладывает его по ресурсам в БД для возможности получения необходимой информации. 
• МИС и СОМР могут изменять статусы рецепта, проставляя отметки о порче рецепта, о постановке на отложенное обслуживание, об отоваривании рецепта. 
• МИС может получать статус рецепта для отображения его врачу

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

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

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

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

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

Базовая схема информационного взаимодействия