Интеграции с МИС
Интеграция сайта с МИС: что выяснить до оценки проекта
Что запросить у поставщика МИС, как сравнить виджет и собственную разработку, проверить запись без дублей и понять, из чего складывается стоимость интеграции.
Представьте: пациент выбрал на сайте приём в 15:00. Пока он вводил телефон, администратор занял это время в медицинской информационной системе — МИС. Сайт успел показать «Вы записаны». Кто теперь разбирается с двумя пациентами?
Это условная ситуация, которую полезно разобрать до оценки проекта. Формулировка «интегрировать сайт с МИС» не говорит, какая система подтверждает запись, как обрабатываются отмены и что происходит при потере связи. Эти решения определяют и работу регистратуры, и объём разработки.
Сначала решите, нужна ли собственная разработка
Если задача — показать расписание и дать пациенту записаться, начните с демонстрации готового решения поставщика. Проверьте его на своём сценарии: несколько филиалов, разная длительность приёмов, первичный и повторный визит. Иногда нужный результат даёт настройка модуля, который клиника уже приобрела.
У «Инфоклиники», например, опубликованы демонстрации виджетов и SDK — набора инструментов для встраивания своих интерфейсов. Это разные варианты подключения. У «Медиалога» в каталоге есть готовые решения для пациентов и интеграционная шина «Телемедиалог». Наличие продукта в каталоге ещё не означает, что он включён в договор вашей клиники.
Свой интерфейс имеет смысл обсуждать, когда готовый вариант не проходит конкретную проверку: нельзя выбрать нужную комбинацию врача и услуги, поддержать правила сети или связать запись с другим сервисом. Зафиксируйте этот разрыв. Он объяснит, за что клиника платит разработчику.
Источники: Инфоклиника: демонстрации SDK и виджетов; Медиалог: каталог продуктов и Телемедиалог.
Пять ответов от поставщика МИС до сметы
Название МИС — только начало. Для оценки нужны установленная версия, подключённые компоненты и доступные операции. API, то есть программный интерфейс обмена, может разрешать чтение расписания, но не создание или отмену записи.
Попросите поставщика ответить письменно на вопросы ниже. Ответы «есть API» и «у нас всё стандартно» оставляют стоимость проекта зависимой от предположений.
| Вопрос | Что получить |
|---|---|
| Что установлено? | Название продукта, конфигурация, релиз, филиалы и схема размещения. |
| Какие действия доступны? | Отдельно: расписание, создание, перенос и отмена записи. Для кабинета — документы и результаты. |
| Что нужно оплатить? | Модули, лицензии, доступ к интерфейсу, работы вендора и регулярная поддержка. |
| По чему разрабатывать? | Документация к этой версии, примеры ошибок, ограничения по запросам и правила обновлений. |
| Где проверить? | Тестовый контур, искусственные пациенты и сотрудник, который выдаст доступ и поможет проверить результат в МИС. |
Источники: 1С:Предприятие: REST-интерфейс платформы.
Разберите одну запись от начала до конца
Для каждого вида данных назначьте источник, которому доверяют остальные системы. Например, в выбранной архитектуре расписание и факт записи подтверждает МИС, а сайт показывает результат. Тогда устаревший список свободного времени на сайте не даёт права обещать пациенту приём.
Отдельно согласуйте два состояния: «заявка отправлена» и «запись подтверждена». Если клиника требует звонка администратора, сайт должен объяснять этот порядок. Если подтверждение автоматическое, его показывают после принятия записи МИС.
Самая неудобная ошибка — потеря ответа. МИС могла сохранить запись, а сайт не получил подтверждения. Повторная отправка не должна создавать вторую запись. Нужен согласованный способ определить судьбу первой операции, а не бесконечно повторять её.
Так же разберите отмену: кто меняет статус, когда время снова становится доступным, как отменяется запланированное напоминание. Назначьте сотрудника, который видит незавершённые операции и может их разобрать. Иначе техническая очередь превращается в неизвестную регистратуре задолженность перед пациентами.
Где здесь HL7 и FHIR
HL7 v2 и FHIR задают способы обмена медицинской информацией. Для заказчика важен следующий вопрос: поддерживают ли обе стороны нужную операцию в совместимых версиях и согласованном составе данных? Название стандарта на слайде этого не подтверждает.
В описании «Медиалог 2.0» перечислены REST/gRPC, HL7 v2 и FHIR. Это сведения о конкретном продукте: их нельзя переносить на любую старую установку «Медиалога». Для интерфейса FHIR запросите версию и описание возможностей развёрнутой системы — CapabilityStatement, если поставщик его предоставляет.
Для записи на сайте может быть достаточно прикладного API или готового модуля МИС. Для обмена с лабораторией состав данных и проверки будут другими: направление, исследование, результат, исправленная версия результата. Авторизацию и доступ к чужим документам проверяют отдельно: FHIR сам по себе не является протоколом безопасности.
Источники: Медиалог 2.0: API и наборы правил; HL7 FHIR R4: CapabilityStatement; HL7 FHIR R4: безопасность.
Что показать на приёмке, кроме успешной записи
Ниже — примеры проверок для проекта с подтверждением записи в МИС. Согласуйте ожидаемое поведение со своей регистратурой и поставщиком. Проведите проверки на тестовых данных и сохраните результаты в протоколе приёмки.
| Исходная ситуация и действие | Ожидаемый результат |
|---|---|
| Два пользователя одновременно выбирают один слот, рассчитанный на одного пациента | МИС подтверждает одну запись. Второй пользователь получает понятное предложение выбрать другое время. |
| МИС приняла запись, но ответ не дошёл; запрос повторён | Проверяется результат первой операции. Вторая запись не появляется. |
| Администратор отменил запись в МИС | Статус на сайте меняется по согласованному правилу; отменённое посещение не остаётся в напоминаниях. |
| Во время оформления МИС перестала отвечать | Сайт не показывает ложное подтверждение. Незавершённая операция видна ответственному. |
| После сбоя обмен возобновился | Операции сверены и обработаны без потерь и дублей; нерешённые случаи вынесены на разбор. |
| Если есть кабинет с документами: пациент открывает документ другого тестового пациента | Документ не выдаётся, в том числе при прямом обращении к API. |
Из чего складывается стоимость интеграции
Просите разделить смету на обследование и проверку интерфейса, разработку сценариев, испытания, запуск и сопровождение. Отдельными строками должны идти платежи поставщику МИС, инфраструктура и работы на стороне клиники. Тогда можно сравнить два предложения по одинаковому объёму.
На бюджет влияет число операций и исключений, а не только количество подключённых систем. Выгрузка расписания и двусторонняя запись с отменами — разные проекты. Проверка реального интерфейса до основной разработки уменьшает число неизвестных в оценке.
Разделяйте рабочее время команды и ожидание доступов, документации или обновления МИС. В плане у каждого такого условия должен быть ответственный. Для сопровождения выясните, кто проверяет обмен после обновления МИС и за чей счёт устраняются несовместимости.
До встречи с подрядчиком подготовьте описание текущего пути записи, ответы вендора и три сценария, которые обязательно должны заработать. Этого достаточно, чтобы начать предметный разговор о границах проекта.
Интеграция сайта с МИС в Константе: состав работ и стоимость