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

О нашем новом продукте расскажем подробно в этой статье. План такой:

  • зачем нужен Медицинский голосовой помощник;
  • основные сценарии использования;
  • из каких компонентов состоит решение;
  • как происходит обработка и назначение задач.


Как работает МГП

Зачем нужен Медицинский голосовой помощник (МГП)


МГП решает две основные задачи.

  • Помощь обездвиженным пациентам. Больные в палатах обращаются к медперсоналу исключительно голосом, не нажимая на кнопки: вызывают врача, запрашивают (и получают) консультацию, самостоятельно записываются на процедуры, узнают расписание работы нужного кабинета.
  • Учёт и автоматическая обработка запросов. Руководству больниц МГП помогает упорядочить загрузку персонала, правильно распределять приоритеты и не отвлекать специалистов на задачи, которые не требуют посещения палат. В результате врачи и медсёстры/медбратья занимаются важными задачами, уровень стресса персонала снижается.

Базовые сценарии


Здесь мы рассмотрим базовые сценарии использования голосового помощника, которые подходят практически любой больнице. Разумеется, вариантов может быть гораздо больше — всё зависит от потребности конкретной клиники.

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

Автоматическое выполнение запроса. Пациент запрашивает справочную информацию, которая уже есть в базе знаний, — например, расписание работы столовой. МГП находит соответствующую статью по ключевым словам и озвучивает её пациенту. Пациент доволен, медсёстры тоже: они могут заниматься более важными задачами.

Двусторонняя связь. Применяется, когда больному требуется консультация специалиста — например, если нужно узнать у лечащего врача подробности о дозировке и графике приёма нового лекарства.

Компоненты МГП


Медицинский голосовой помощник может решать множество задач, от простых до самых сложных. Однако его многофункциональность сочетается с простотой реализации. На уровне компонентов это довольно минималистичное программно-аппаратное решение — к этому мы стремились сознательно.

МГП включает 4 базовых модуля.

  1. Терминал пациента. Состоит из микрофона для приёма звука, колонок для воспроизведения сообщений системы (и врачей) и микрокомпьютера, который обрабатывает информацию пациента и взаимодействует с другими компонентами.
  2. Система распознавания и синтеза речи. Систему можно использовать в облаке или установить локально.
  3. Система учёта и обработки запросов. Веб-приложение, в котором работает медперсонал. Реализовано на базе ESM-платформы для автоматизации бизнес-процессов SimpleOne.
  4. Терминалы врачей и медперсонала. Планшеты или ПК, которые подключены к системе учёта и обработки запросов по Wi-Fi или по LAN.

Обработка голосовых запросов


Терминал в палате выступает в роли узла связи между пациентом, Системой распознавания и синтеза речи (СРС) и Системой учёта и обработки запросов (СУЗ).

В общем виде процесс обработки запроса выглядит так:

  • терминал постоянно ожидает ключевого слова;
  • если произнесено ключевое слово, терминал записывает короткое аудио (4–5 с);
  • аудио отправляется в СРС;
  • ответ от СРС терминал отправляет в СУЗ;
  • терминал озвучивает информацию пациенту в зависимости от преднастроенной логики СУЗ (шаблона).


На скриншоте — пример обработки запроса с записью на рентген

Для более комфортного взаимодействия, кроме стандартных ответов «Ваш запрос принят, ожидайте помощи», МГП воспроизводит специальные сигналы — например, о начале и об окончании записи сообщения пациента.

Назначение задач на основе шаблонов


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

В системе есть таблица «Сообщения», в которой хранятся все произнесённые пациентом фразы. Система мониторит таблицу поступающих сообщений и создаёт запрос, если сообщение попадает под условие шаблона.

Пример


Для шаблона запроса «Обезболивающее пациенту» выбираем ключевое слово «больно». Присваиваем запросу высокий приоритет, выбираем метод «Медперсонал» и подключаем нужную группу исполнителей — медсестёр. Теперь, если больной скажет «больно», МГП автоматически назначит задачу на группу «Медсёстры». Участники группы получат уведомление о назначении задачи; сообщение пациента отразится в поле «Описание» запроса.


Вид шаблона запроса

Параллельно задача зафиксируется в счётчике контроля времени реакции (SLA). В нашем примере на решение проблемы отводится 10 минут. Если специалист не укладывается в срок, проблема эскалируется на вышестоящего врача или группу (сценарии эскалации также настраиваются).


Счётчик SLA

В системе можно создавать неограниченное количество шаблонов запросов. Делать это могут сотрудники с правами администратора.


Шаблоны запросов

Почему мы выбрали Pocketsphinx, Python и SQLite3


В прототипе решения мы использовали микрокомпьютер семейства Raspberry Pi и базовую ОС Raspbian GNU/Linux. Терминал — это простое приложение, написанное на Python с использованием REST-запросов к вспомогательным системам, а также библиотеки Pocketsphinx (LiveSpeech).

Библиотека Pocketsphinx хороша тем, что помогает повысить быстродействие первого отклика — поиска ключевого слова. Система распознавания и синтеза речи использует сложные механизмы и словари для распознания. Грубо говоря, Pocketsphinx ускоряет процесс распознания ключевого слова, чтобы не возникало негативного клиентского опыта. Ещё Pocketsphinx проста в настройке и может работать в нескольких режимах.

Использование Python и Pocketsphinx значительно расширяет функциональные возможности терминала. Чтобы пациенты не скучали, в МГП можно добавить игры. В прототипе мы, например, реализовали простую игру «Города».

Для интеграции СРС и СУЗ используется стандартный REST API.

Ниже — пример обращения СУЗ (отправляем POST-сообщение в сторону СУЗ, парсим ответ, и так по кругу):

url = 'https://user:pass@mva.simpleone.ru/rest/v1/table/mva_itguild_inquiry'
payload = {«description»: text, «subject»: «mva_inquiry»}
header = {'Accept': 'application/json;charset=UTF-8','Content-Type': 'application/json;charset=UTF-8'}
response = requests.post(url,data=json.dumps(payload), headers=header)
i_json = response.json()

Постоянный синтез речи с помощью СРС — процесс небыстрый, потому что довольно ёмкий: авторизация, запрос, обработка. Чтобы его ускорить, используется локальная база данных SQLite3 для хранения уже сгенерированных ранее ответов пациенту. Такое решение хорошо подходит для обработки запросов с постоянным сценарием — например, при озвучивании информации о расположении кабинетов врачей и процедурных, расписании работы столовой.

Другой важный момент — логирование. Без него невозможно работать над улучшениями и устранением ошибок. Поэтому в терминале реализовано логирование как общего процесса работы всех смежных систем, так и отдельных компонентов.

Что в итоге


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

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