Голосовой ввод медицинских заключений для врачебного сервиса

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

Мы не стали спорить о движках теоретически. Собрали набор реальных надиктовок разной длины и с разным темпом речи и прогнали одни и те же записи через оба варианта. Microsoft Speech-to-Text на англоязычной медицинской речи давал меньше правок и устойчивее держал длинные фразы: там, где предыдущий движок разрывал предложение на середине и терял окончание мысли, новый доводил фразу до конца. По итогам сравнения движок заменили.

Замену сделали так, чтобы для врача ничего не изменилось внешне: та же кнопка, то же поведение, тот же индикатор записи. Переучивать людей на середине проекта — верный способ получить отказ от инструмента. Изменилось только качество текста, который появляется в поле.

Самая наглядная претензия заказчика звучала так: фамилия Genese распознаётся как Chinese. Это хорошая иллюстрация проблемы — движок общего назначения подставляет частотное слово вместо редкого имени собственного, и формально он даже прав, а по факту заключение испорчено.

Мы подключили собственный словарь и, что важнее, наладили процесс его пополнения:

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

Отдельная история — форма заключения. Пока текст набирали руками, он был коротким: печатать долго, врач формулировал сжато. Как только заключение начали диктовать, объём вырос — говорить быстрее, чем печатать. Текст перестал помещаться в поля фиксированной высоты: врач видел последние строки и не видел начала, приходилось прокручивать внутри поля и терять контекст.

Мы сделали поля адаптивными: они растут под объём продиктованного, заключение видно целиком, а форма при этом не разъезжается. Мелочь, которая напрямую влияет на то, будут инструментом пользоваться или нет.

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

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

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