Клиника, которая заключила договор с НСЗУ по программе медицинских гарантий, обязана передавать данные в центральный компонент электронной системы здравоохранения eHealth. Своя программа, удобная врачам внутри клиники, может не пройти проверку на соответствие регламенту, и тогда требование не выполнено. Для медицинской клиники Evrika мы разобрали документацию eHealth и требования к интеграции, чтобы до разработки понять, что именно должна уметь её медицинская информационная система (МИС).
Требование: МИС подключена к eHealth
По состоянию на 2020 год отправлять данные в центральный компонент обязаны все медицинские учреждения с договорами НСЗУ. Для этого их МИС должны быть подключены к eHealth. Решение о подключении принимает ГП «Электронное здоровье» после тестирования функций на соответствие техническому регламенту.
Схема ниже показывает принцип: несколько МИС передают данные в центральную базу, с которой работают частные медучреждения, телемедицина, страховые, аптеки, лаборатории, частные больницы и академические медцентры.
Для кого этот разбор
- частные клиники и медцентры с договором НСЗУ, у которых есть своя программа или планируется собственная;
- сети медцентров, где одна система обслуживает несколько филиалов;
- разработчики МИС, которым нужно пройти подключение без многократных переделок.
Как устроена eHealth
На общей схеме eHealth на 2021 год видны шлюз, слой интеграции, реестр пациентов, верификация по одноразовому коду, цифровая подпись, отчётность и медиахранилище. МИС клиники разговаривает с этой системой только через API.
Отдельно мы разобрали общую схему модулей Администратора СМД и Рабочего места врача СМД системы eHealth.
Главное в интеграции: методы API и документ требований
В общих чертах интеграция одной программы с другой означает интеграцию API, поэтому разбор документации и методов API здесь ключевой. Каждый метод описан с адресом, параметрами и примерами ответа.
Документация методов доступна по ссылке https://ehealthmisapi1.docs.apiary.io/#reference/p...
Кроме API есть документ, требования которого должны быть соблюдены при интеграции МИС в eHealth. Именно по нему проверяется функциональность перед подключением.
Разные модели данных: «приём» и «эпизод»
Сложность в том, что структура и названия в программе клиники и в eHealth разные, и их нужно сопоставить. Например, в вашей программе консультация пациента может называться «приём», и приёмы связаны только через пациента. В eHealth есть «эпизод», который включает в себя «визиты», и пока не поставлен диагноз, врач эпизод не закрывает.
Процесс ведения медзаписей выглядит так: обращение пациента, идентификация, проверка направления (если оно есть, его ищут в системе, если нет, ищут пациента), создание эпизода, поиск эпизода, внесение медицинских записей и закрытие эпизода.
Пример требования: жизненный цикл эпизода
На практике программа для успешной интеграции должна соответствовать требованиям по каждому объекту. Пользователю должна быть предоставлена возможность выполнить в соответствии со спецификацией API следующие действия:
- создать «Епізод МД» (метод «Create Episode»);
- найти эпизод по поисковым параметрам: пациент, период, код, статус, организация, с постраничной выдачей от 1 до 100 записей (по умолчанию 50);
- обновить доступные для редактирования параметры эпизода (метод «Update Episode»);
- отметить эпизод как «введений помилково» (метод «Cancel Episode») с обязательным обоснованием (параметр «explanatory_letter») и причиной из справочника (параметр «status_reason»);
- закрыть эпизод (метод «Close Episode») с обязательным обоснованием закрытия (параметр «closing_summary»).
Правила проверки эпизода: https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583402023/Create+Episode
Справочники и электронная подпись
Помимо основных функций интегрируются справочники: диагнозы, декларации, сотрудники, отделения клиники, города, улицы, роли пользователей, оборудование. Нужна и система электронной подписи: врач подписывает диагноз своим ключом. Схема выше показывает, как устроена электронная идентификация через квалифицированную электронную подпись и через паспорт в форме ID-карты.
Что клиника получает после такого анализа
- карту соответствия своих сущностей объектам eHealth: приём, эпизод, визит, медзапись;
- перечень методов API с обязательными параметрами для каждого сценария врача;
- список справочников, которые нужно синхронизировать;
- требования к подписи и идентификации;
- основу для ТЗ и расчёта по этапам. Как мы ведём такие работы, описано в статье про этап интеграций.
Честная граница: это анализ и проектирование. Решение о подключении принимает ГП «Электронное здоровье» после тестирования, а схемы и требования относятся к 2020-2021 годам, поэтому перед разработкой мы сверяем их с актуальной документацией.
Где ещё это применимо
Тот же подход нужен разработчикам МИС, лабораториям и аптекам, а также любой компании, которой предстоит интеграция с государственным реестром или API со строгим регламентом. Как выглядит приложение пациента и кабинет врача, показано в кейсе Lita Doctor.
Если Вашей клинике предстоит интеграция с eHealth, запишитесь на бесплатную консультацию с архитектором. После неё Вы получите расчёт цены и сроков по этапам.
