Интеграция с МИС: как сделать сервис эффективным и удобным для людей

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

Техническая сторона: какими способами программы «общаются» между собой

Выбор способа обмена данными API (Application Programming Interface) — SOAP (Simple Object Access Protocol) или REST (Representational State Transfer) — определяет логику взаимодействия систем. В медицинской среде оба подхода имеют свои области применения, и понимание их специфики важно для создания надежных интерфейсов.

Пример использования API в жизни:

● Оплата картой: сайт использует API банка для проведения платежа.

● Карты на сайтах: интеграция карт Google или «Яндекса» на сторонних сайтах.

● Войти через Google/VK: использование учетных данных одной системы на другой.

Определение REST и SOAP:

REST (Representational State Transfer) — это архитектурный стиль взаимодействия компонентов распределенных приложений в сети, обычно использующий протокол HTTP (HyperText Transfer Protocol). Он определяет набор правил для обмена данными между клиентом и сервером (например, мобильным приложением и сервером), обеспечивая стандартизированный, гибкий и масштабируемый способ взаимодействия.

SOAP (Simple Object Access Protocol) — это строгий протокол обмена структурированными сообщениями в формате XML (eXtensible Markup Language), используемый для взаимодействия приложений. Он обеспечивает высокую безопасность и надежность, часто применяется в банковских системах и корпоративных сервисах (API), работая поверх HTTP, HTTPS (HyperText Transfer Protocol Secure), SMTP (Simple Mail Transfer Protocol) и других протоколов.

Для простого понимания можно использовать аналогии из жизни:

● SOAP — это официальное заказное письмо в плотном конверте с кучей печатей и подписей. Чтобы его прочитать и подтвердить получение, нужно соблюсти множество формальностей, что делает процесс медленным и тяжелым.

● REST — это быстрая записка, СМС или почтовая открытка. Она короткая, легкая и содержит только самую суть, поэтому передается мгновенно.

Давайте сравним оба метода:

API: что такое «хорошо» и что такое «плохо»

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

Чего стоит избегать

«Плохая» интеграция перекладывает технические проблемы системы на плечи инженера. Это делает сервис нестабильным и сложным в поддержке.

● Низкоуровневые вызовы на этапе выбора услуги: когда для одного простого действия боту нужно вызвать десять разных методов. Логика при этом запутывается. При такой долгой загрузке человек чаще всего просто кладет трубку, не дождавшись ответа. Исследования показывают, что если ожидание превышает 5 секунд, большинство пользователей прекращают общение.

● Сложные форматы данных: получение данных в виде «матрешки» (один код внутри другого). Сценарий не должен заниматься очисткой служебных таблиц с описанием типов и технического шума. Работа с такими данными заметно снижает долю успешно завершенных заявок.

● Сырые данные при идентификации: передача пустых полей или дат в техническом формате. Если процесс подтверждения личности затягивается из-за технических заминок, вероятность того, что человек завершит звонок, вырастает в разы.

● Чрезмерная сложность для медучреждения: иногда системы настолько запутаны, что сами медучреждения не понимают, как правильно заводить в них врачей или услуги. Это ведет к тому, что в справочниках появляются дубли и ошибки, которые не должны исправляться в сценарии робота.

К чему нужно стремиться

«Хорошая» интеграция работает по принципу «одной кнопки»: сценарий просит выполнить действие и получает понятный результат. Это позволяет почти каждому обратившемуся успешно получить услугу.

● Умный выбор услуги через параметры: сервис будет работать гораздо лучше, если вместо цепочки из десяти запросов использовать получение информации через несколько запросов с четкими параметрами.

Пример: вместо того чтобы сначала просить список всех специальностей, потом всех врачей, а потом все даты, лучше использовать метод «Получить свободные слоты», передав в него сразу код специальности и нужный диапазон дат. Это сокращает время ожидания, и человек не бросает трубку.

● Надежная идентификация: система должна позволять быстро и однозначно подтвердить личность пациента. Чаще всего это происходит тремя способами: по ФИО и дате рождения, по номеру СНИЛС или по номеру полиса ОМС. Качественная интеграция позволяет боту мгновенно сверить эти данные с базой.

● Понятные ответы: на этапе получения услуги система возвращает статус: «Пациент не найден», «Найдено несколько совпадений», «Запись успешно создана». Такие сценарии работают гораздо эффективнее других.

● Автоматизация рутины: система сама приводит даты к нужному виду и проверяет обязательные поля.

Что делать, если в системе не хватает данных

Одной из наиболее коварных ловушек при интеграции является интерпретация отсутствующих данных. Поля в МИС могут быть не заполнены по историческим причинам или из-за особенностей работы конкретного отделения.

Интеграционная часть должна выступать в роли «умного фильтра», который оценивает достоверность информации. Например, если для оформления вызова врача на дом требуется адрес, а система возвращает пустую строку, качественный интегратор действует так:

1. Ищет альтернативы: пытается получить адрес из истории предыдущих вызовов пациента у себя внутри.

2. Оценивает важность: проверяет, является ли это поле критическим для данного действия.

3. Запрашивает уточнение: если данные необходимы, система передает в код информацию чтобы в дальнейшем уточнить ее у пациента .

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

Путь пациента: стресс против комфорта

То, как медучреждение настроило методы и справочники в своей системе, напрямую влияет на то, получит ли человек пользу от сервиса.

Вариант «стресс». Организация использует множество мелких методов, а данные в системе заполнены с ошибками (дубли врачей, пустые адреса). Человек хочет записаться, но робот делает 10-15 последовательных запросов, после каждого вопроса наступает долгая пауза. При длительной задержке ответа человек просто кладет трубку. В итоге бот предлагает время, которое уже занято. Человек остается без записи и разочаровывается в сервисе.

● Для инженера такая работа превращается в бесконечное «латание дыр» и ручную чистку данных. До 60-80% времени тратится не на развитие сервиса, а на исправление ошибок и попытки понять, почему цепочка запросов оборвалась.

● Итог: проект обрастает техническим долгом, становится очень дорогим в обслуживании, а любые изменения в МИС приводят к полной остановке сервиса.

Вариант «комфорт». Организация настроила получение информации посредством нескольких запросов с параметрами.

1. Выбор услуги. Человек говорит: «Запиши к терапевту на завтра». Система мгновенно находит доступные варианты.

2. Идентификация. Робот быстро находит пациента по ФИО, СНИЛС или ОМС.

3. Получение услуги. Бот предлагает время: «Есть на 10:00 и 11:30. Какое выбрать?». После ответа запись подтверждается мгновенно.
Человек быстро и четко записывается к врачу, он доволен, а медицинская организация получила запись без лишних усилий персонала. В медицине такая скорость работы значительно увеличивает количество реальных визитов граждан к врачам.

● Инженер в такой системе работает с готовыми и надежными блоками данных. Это позволяет внедрять новые функции (например, автоматические опросы о качестве обслуживания) за считанные часы, а не недели.

● Итог: создается масштабируемая система с низкими затратами на поддержку, которая стабильно работает и легко растет вместе с потребностями организации.

Итог правильной интеграции

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

И при правильной (хорошей) интеграции конверсия сервисов, например «запись на прием к врачу» или «вызов врача на дом», будет превышать 70%, при «плохой» будет втрое меньше.

Михаил Гончарук, руководитель проектов департамента голосовых цифровых технологий компании BSS