Транскрипция и субтитры консультаций в реальном времени

Это инженерные рекомендации, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Кратко

Транскрипция в реальном времени превращает речь на телемедицинской консультации в текст: в субтитры, которые пациент читает на экране, пока врач говорит, и в письменную запись сказанного. В её основе тот же первый шаг, что и у ИИ-скрайба (автоматическое распознавание речи, ASR), но задача другая: скрайб готовит структурированный протокол, а транскрипция выдаёт сами слова – сразу, для доступности и для записи. Для глухих и слабослышащих пациентов субтитры – способ вообще участвовать в видеоконсультации: 181-ФЗ задаёт общую обязанность обеспечивать людям с инвалидностью доступность услуг, а технической планкой служит ГОСТ Р 52872-2019, построенный на WCAG 2.1. Аудио консультации и его транскрипт – сведения о здоровье и врачебная тайна, поэтому распознавание работает либо в вашем контуре (on-prem: SpeechKit Hybrid, открытая модель Whisper), либо у российского провайдера по поручению обработки (SaluteSpeech, Yandex SpeechKit) – с данными в России. Зарубежные облачные ASR-API для медданных не используются: это трансграничная передача специальной категории данных и конфликт с требованием о локализации. В статье – как работают живые субтитры, где проходит граница медданных, насколько точно распознаётся медицинская речь и как выбрать движок.

Зачем это читать

Если вы строите или ведёте телемед-продукт, субтитры – ИИ-функция, о которой команды чаще всего забывают, пока жалоба глухого пациента или требование заказчика не заставит ими заняться. Глухой или слабослышащий пациент должен общаться с врачом так же полноценно, как любой другой, а на видеоплатформе для этого часто нужны точные субтитры в реальном времени. При этом каждое слово, которое выдаёт движок субтитров, – данные пациента, поэтому на распознавание распространяются те же правила защиты медданных, что и на весь остальной продукт. До проработки функции основателю или продакт-лиду нужно знать три вещи: когда субтитры нужны и какое качество считать достаточным, где транскрипт покидает ваш контур и насколько точно на самом деле распознаётся медицинская речь. Неверно распознанное название лекарства в субтитрах – проблема безопасности пациента, а не опечатка.

Транскрипция и скрайб – разные функции

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

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

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

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

Нажмите, чтобы увеличить

Как работают живые субтитры

Технически субтитры – первая половина конвейера скрайба, работающая в реальном времени. Движок тот же: автоматическое распознавание речи (ASR) – программа, которая превращает речь в текст. Разница в том, что субтитры должны появляться, пока человек ещё говорит, и это меняет всю инженерную задачу.

Нажмите, чтобы увеличить

Потоковый режим вместо пакетного. Скрайб может дождаться конца консультации и обработать всю запись разом – это пакетная (batch) транскрипция. Субтитры ждать не могут. Им нужно потоковое распознавание: аудио непрерывно уходит в движок, а слова возвращаются фрагментами за доли секунды; Yandex SpeechKit, например, прямо называет потоковый режим инструментом для живых субтитров [1]. Цена скорости – движок выдаёт слова, не дослушав фразу, и исправляет их, когда появляется контекст. Поэтому живые субтитры иногда мигают и меняются через мгновение после появления: движок услышал «начнём с метро…» и угадал, затем поправил на «метопролол», когда пришла остальная часть слова. Открытая модель Whisper изначально рассчитана на обработку фрагментов записи окнами по 30 секунд [2], поэтому для живых субтитров ей нужна обвязка, нарезающая поток, – и задержка у такой схемы выше, чем у полноценного потокового режима.

Задержка – главное ограничение. Чтобы субтитры воспринимались синхронно с речью, слова должны появляться примерно через секунду после произнесения. Если задержка заметно больше, субтитры отстают от разговора: это отвлекает, а в клиническом диалоге ещё и путает, кто на что отвечает. Как устроено потоковое распознавание изнутри – какие модели, как они работают в реальном времени, как поток распределяется (fan-out) на медиасервере, – разобрано в разделе об ИИ в видеоинженерии: потоковое распознавание речи и живые субтитры на стороне SFU; здесь речь о клинике и защите данных.

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

Когда без субтитров не обойтись

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

Нажмите, чтобы увеличить

Уровень первый – общая обязанность доступности. Федеральный закон № 181-ФЗ «О социальной защите инвалидов в Российской Федерации» задаёт общую обязанность обеспечивать людям с инвалидностью доступность услуг; медицинская консультация – тоже услуга [3]. Конкретных технических решений закон не называет, но глухой пациент, который не может участвовать в видеоконсультации, получает недоступную услугу – а это жалоба и риск для клиники. Тот же закон признаёт русский жестовый язык языком общения при нарушениях слуха и (или) речи, а переводят с него квалифицированные переводчики (ч. 2 ст. 14) [4]. Для части глухих пациентов субтитры не заменяют переводчика РЖЯ, и платформа должна уметь подключить его к звонку – об этом статья о многосторонних консультациях и переводчиках.

Уровень второй – ГОСТ Р 52872-2019 и WCAG 2.1, техническая планка. Когда заказчик или проверяющий спрашивает, доступна ли ваша цифровая услуга, ориентиром служит ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». Он построен на WCAG 2.1 – Руководстве по доступности веб-контента консорциума W3C – с уровнями A, AA и AAA, действует с 1 апреля 2020 года и применяется добровольно [5][6]. Критерий WCAG 1.2.4 «Субтитры (в реальном времени)» уровня AA требует субтитров для живого аудио, причём субтитры должны не только передавать слова, но и указывать говорящего и значимые звуки [7]. Есть нюанс: авторы WCAG отмечают, что критерий 1.2.4 написан с прицелом на вещательные медиа и «не предполагал требовать», чтобы двусторонние мультимедийные звонки между двумя или более людьми субтитрировались независимо от потребности. Поэтому обычная консультация один на один сама по себе под критерий 1.2.4 не подпадает – этот пробел закрывает первый уровень. А вот вебинары, школы пациентов и групповые сессии на вашей платформе подпадают под него напрямую, а для записанных обучающих материалов действует соседний критерий 1.2.2 о субтитрах к записи.

Уровень третий – договор с заказчиком. Добровольный стандарт становится обязательным, когда его включают в техническое задание. Государственная клиника, региональная программа или крупная сеть могут потребовать соответствия ГОСТ Р 52872-2019 в договоре на разработку – и тогда это уже не пожелание, а критерий приёмки.

Продуктовой команде стоит встроить субтитры с самого начала и считать их частью доступности продукта, а не опциональной функцией: тогда вы готовы, какой бы уровень требований ни применялся к вашим клиентам. Если прикручивать их после жалобы, дорабатывать придётся в спешке. Доступность клинического видео в целом – контраст, управление с клавиатуры, поддержка программ экранного доступа – разобрана в статье WCAG 2.1 AA и ГОСТ Р 52872-2019 для телемед-видео.

Граница медданных: транскрипт – это данные пациента

Дальше – то, что роднит транскрипцию со всеми ИИ-функциями этого раздела. Слова, которые выдаёт движок субтитров, касаются здоровья пациента, произнесены на консультации и привязаны к конкретному человеку. Это сведения о здоровье – специальная категория персональных данных (ст. 10 152-ФЗ) – и врачебная тайна (ст. 13 323-ФЗ) [8][9]. Субтитр, в котором пациент описывает свои симптомы, – такие же медданные, как исходное аудио.

Поэтому центральный вопрос карты ИИ в телемед-продукте здесь встаёт в полную силу: аудио уходит в сервис распознавания, чтобы превратиться в текст, – покидают ли медданные ваш контур, и если да, кто их получает, на каком основании и где?

Основание. Провайдер распознавания, получающий аудио консультации, обрабатывает данные от имени клиники – это лицо, действующее по поручению оператора (ст. 6 ч. 3 152-ФЗ). В поручении – перечень данных и действий, цели, обязанность соблюдать конфиденциальность, требования к защите по ст. 19 и обязанность сообщать оператору об инцидентах; подписано оно должно быть до того, как к провайдеру попадёт хоть одна секунда реального аудио [10]. Пункт, который легко упустить: обучение моделей провайдера на разговорах ваших пациентов – уже его собственная цель, а не цель клиники. Пропишите явно, что аудио и транскрипты не используются для обучения и улучшения моделей и удаляются после обработки.

Место. С 1 июля 2025 года 152-ФЗ прямо запрещает вести базы с персональными данными граждан РФ за рубежом (ст. 18 ч. 5), а отправка данных зарубежному провайдеру – трансграничная передача, о которой нужно заранее уведомить Роскомнадзор (ст. 12) [8]. Для аудио консультации – специальной категории под врачебной тайной – этот путь на практике закрыт. Поэтому распознавание медицинской речи в России собирают из компонентов двух типов: облачных API российских провайдеров – SaluteSpeech (Сбер) и Yandex SpeechKit – по поручению, с данными в России [11][1], или моделей on-prem: SpeechKit Hybrid либо открытая модель Whisper [2] в вашей инфраструктуре или в аттестованном российском облаке [12]. Подробнее – в статье о локализации данных и о том, где хранятся медданные.

Ловушка та же, что и у любой ИИ-функции: «провайдер готов работать по поручению» и «ваше использование покрыто договором» – два разных факта. Стандартные условия облачного API нужно сверить с вашим сценарием: оформлено ли поручение, где обрабатывается и хранится аудио, используется ли оно для обучения. А встроенная в браузер функция распознавания речи обычно отправляет аудио на серверы производителя браузера – часто за рубеж и без всякого договора с вами, – поэтому для клинических субтитров она исключена. Как устроена цепочка договоров, разобрано в статье о поручении обработки ПДн и договорах с подрядчиками.

Что вы храните – отдельное решение

Субтитры и транскрипты резко расходятся по одному вопросу – хранению. Живые субтитры можно вообще не сохранять. Они появляются на экране, пациент их читает, и они исчезают. Функция, сделанная только ради доступности, может ничего не хранить, и это самый надёжный вариант: медданные идут в движок внутри контура, возвращаются текстом, отображаются и никогда не пишутся на диск.

Как только вы сохраняете транскрипт, на него распространяются все правила хранения медданных: шифрование, контроль доступа и журнал, где видно, кто его открывал (регистрация событий безопасности – одна из мер приказа ФСТЭК № 21) [13]. Сохранённый транскрипт – ещё и материал консультации. Порядок телемедицины не обязывает записывать консультации, но если аудио- и видеозаписи, текстовые и голосовые сообщения сделаны, они хранятся как сопутствующие материалы один год (приказ 193н, п. 49–51); заключение и протокол хранятся в медицинской документации по своим срокам [14]. Относится ли сохранённый транскрипт к сопутствующим материалам или становится частью медицинской документации – уточните у юриста: от ответа зависят срок хранения и право пациента получить копию (ст. 22 323-ФЗ) [15]. Порядок 193н также требует раскрывать пациенту на сайте или в приложении оператора информационной системы и место хранения материалов (п. 37). Механика согласия и хранения – в статье согласие пациента, запись и хранение данных.

Отсюда то же правило проектирования, что и везде в 152-ФЗ, – принцип минимизации: объём данных соответствует целям, лишнее не обрабатывают и не хранят дольше нужного (ст. 5) [8]. Осознанно решите, нужен ли сохранённый транскрипт вообще. Если субтитры существуют только ради доступности, не хранить ничего и проще, и безопаснее. Если вы сохраняете транскрипты – для записи, для скрайба, для контроля качества, – обращайтесь с ними как с чувствительными клиническими материалами – ведь это они и есть – и информируйте пациента.

Насколько точно распознаётся медицинская речь?

Именно точность делает транскрипцию клинически значимой: субтитр читают сразу, а транскрипту доверяют и потом. Главная метрика – доля ошибок по словам (word error rate, WER): доля слов, которые движок распознаёт неверно. Речевые модели общего назначения хорошо справляются с повседневным разговором и ошибаются на медицинской лексике: названия препаратов, анатомические термины, дозировки и сокращения – как раз те слова, которые реже всего встречаются в обучающих данных.

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

Важнее любой общей цифры другое: оставшиеся ошибки скапливаются в самом опасном месте – в клинических сущностях. Модель может показать низкий общий WER и всё же путать названия лекарств, диагнозы и значения анализов, потому что эти слова редки и легко смешиваются (вспомните «гидроксизин» и «гидралазин»). Поэтому исследователи измеряют отдельную медицинскую ошибку именно на диагнозах, процедурах и названиях лекарств [16]. Для продукта отсюда правило: измеряйте точность на словах, ошибка в которых может навредить, ставьте строгую планку для названий лекарств и аллергий, проверьте, можно ли подать провайдеру словарь терминов или дообучить модель (у разных провайдеров по-разному), и никогда не позволяйте непроверенному транскрипту подменять медицинскую документацию. Субтитр с неверно распознанным названием лекарства – не опечатка, а угроза безопасности пациента: рано или поздно найдётся читатель, который ему поверит.

Последний пункт удерживает транскрипцию и по безопасную сторону линии медицинского изделия. Движок субтитров или транскрипции записывает сказанное: он не ставит диагноз, не лечит и не рекомендует. Пока он остаётся описательным – слова на входе, слова на выходе, – это документирование, и такую функцию обычно не позиционируют как медизделие. Если функция начнёт подсказывать диагноз или лечение, она превращается в систему поддержки принятия врачебных решений, а программное обеспечение с ИИ по классификации Минздрава относится к классу риска 3 (приказ № 4н от 06.06.2012, п. 15.1.1) и требует государственной регистрации как медизделие (ПП № 1684) [17][18]. Подробнее – в статье о скрайбе и в материале о слое комплаенса и безопасности клинического ИИ.

Выбор движка распознавания

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

Нажмите, чтобы увеличить

Читайте таблицу с последнего столбца. Зарубежные облачные API не проходят по локализации и трансграничной передаче, а встроенное распознавание браузера отправляет аудио производителю браузера без договора – оба пути должны быть заблокированы для клинического использования. У российских облачных провайдеров формулу «работаем по поручению» всё равно нужно проверить: покрывает ли договор именно ваш сценарий, обрабатываются и хранятся ли данные в России, не идут ли они на обучение моделей. On-prem даёт больше всего контроля, и его проще всего обосновать перед службой безопасности клиники, но он требует GPU, MLOps и собственной оценки качества: выбирайте его, когда распознавание – ядро продукта или когда клиника не готова выпускать аудио из своего контура. Помимо основания, взвесьте три вещи: насколько модель ошибается на лексике вашей специальности, достаточно ли низка потоковая задержка, чтобы субтитры ощущались живыми, и есть ли полезные дополнения – например, маскирование персональных данных в тексте до того, как он уйдёт в аналитику.

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

Частая дорогая ошибка

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

Решение скучное и без исключений: каждый движок, который может получить доступ к аудио консультации или транскрипту, внесён в утверждённый список и работает по поручению в России или в вашем контуре, а потребительские пути – API браузера, публичные чат-боты – заблокированы. Сделайте правильный путь самым лёгким прямо в продукте, например переключателем субтитров, подключённым к утверждённому движку, иначе победит удобный обходной. Вторая по частоте ошибка – относиться к непроверенному транскрипту как к медицинскому документу: живые субтитры – средство доступности и черновая запись, а не проверенный клинический документ, и всё, что становится частью медицинской документации, врач проверяет и подписывает УКЭП.

Где здесь Фора Софт

Мы строим телемедицинские и видеоплатформы реального времени, к которым подключаются субтитры и транскрипция, и начинаем с границы медданных: путь данных пациента и доступность продумываем раньше функций. Когда клиент хочет живые субтитры, мы направляем аудио консультации в движок внутри контура (on-prem или у российского провайдера по поручению), добиваемся задержки, при которой субтитры успевают за речью, делаем их частью доступности по ГОСТ Р 52872-2019 и WCAG 2.1 AA и осознанно решаем вопрос хранения: где хранить ничего не нужно – субтитры без сохранения, где нужно – зашифрованные транскрипты с журналом доступа. Модель распознавания сегодня можно взять готовой; основная инженерная работа – правильно расположить её относительно границы медданных и требований доступности. От этого зависят и успешный запуск, и удобство пациентов, которым субтитры действительно нужны.

Главное

• Транскрипция выдаёт дословный текст в реальном времени, скрайб готовит структурированный протокол; это разные функции.
• Субтитры работают на потоковом распознавании речи: слова появляются примерно за секунду.
• Для глухих и слабослышащих пациентов субтитры – условие доступности услуги (181-ФЗ); части из них нужен ещё и переводчик РЖЯ.
• Техническая планка – ГОСТ Р 52872-2019 на базе WCAG 2.1 AA; в техзадании заказчика она становится критерием приёмки.
• Транскрипт – медданные: распознавание только в России – по поручению (SaluteSpeech, SpeechKit) или on-prem (SpeechKit Hybrid, Whisper).
• Ошибки скапливаются в названиях лекарств: измеряйте точность на клинических сущностях с учётом падежей.

Что читать дальше

• Амбиентное клиническое документирование: ИИ-скрайб
• Медицинский перевод: ИИ в помощь переводчику
• WCAG 2.1 AA и ГОСТ Р 52872-2019 для телемед-видео