Телемедицина: первичный приём с ИИ-ассистентом

TL;DR

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

Почему это важно

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

Что именно вы строите

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

В индустрии для этого появилось своё выражение: «ИИ становится оболочкой вокруг визита, а не просто стенографистом внутри него». Эта оболочка и есть продукт. Один scribe создаёт запись; система intake-плюс-scribe не только готовит визит, но и замыкает цикл в карте – именно поэтому этот итоговый проект больше по объёму, чем урок про scribe, из которого он вырос, и заслуживает собственной архитектуры.

Два слова в названии продукта несут вес – и оба являются осознанными решениями о границах. Intake означает структурированный сбор повода обращения, симптомов, анамнеза и принимаемых лекарств до подключения врача – но не диагноз и не оценку срочности. Scribe – это фиксация того, что было сказано и решено, но не рекомендация о том, что следует решить. Соблюдая эти две границы, система остаётся ассистентом, который готовит и документирует работу лицензированного специалиста. Пересечь любую из них – например, позволить агенту по сбору данных сообщить пациенту о диагнозе или scribe поставить диагноз самостоятельно – значит создать нечто более сложное, медленнее выводимое на рынок и, как показано в разделе о соответствии, подпадающее под регулирование как медицинское устройство.

Хребет: одно правило, применённое дважды

Две идеи лежат в основе всей сборки. Сделайте их правильно – и всё остальное будет лишь деталями.

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

Вторая идея – чистое аудио от одного говорящего, которое видеовизит даёт вам бесплатно, и это как раз причина, по которой телемедицинский продукт – идеальное место для scribe, а не самое трудное. В обычной клинике ассистент борется с микрофоном комнаты, дальним эхом и двумя-тремя людьми, говорящими одновременно. Видеовизит решает эти проблемы. Связь в реальном времени в вебе – то есть WebRTC, технология, передающая звонок, – отправляет каждого участника отдельной медиадорожкой. Поэтому голос врача и голос пациента приходят двумя отдельными, чётко записанными потоками. Сам по себе этот факт даёт сразу три преимущества: почти студийное качество звука для каждого участника – отсюда более точная транскрипция; диаризацию – задачу определить, кто какие слова произнёс, – почти бесплатно, потому что каждый говорящий уже представлен отдельным потоком, а не смешанным сигналом, который программному обеспечению приходится разбирать задним числом; и естественное место как для записи аудио, так и для получения согласия – ведь самим фактом звонка оно уже получено. Механика подключения к этому аудио – тема урока про SFU-сторонний fan-out ASR.

Держите обе идеи вместе – и у платформы появляется чёткая форма. Паттерн «черновик и подтверждение» решает, что машине позволено делать самой: она может готовить черновик, но не принимать окончательное решение. Факт наличия чистого аудио определяет, где подключается scribe: к уже существующему звонку, а не к отдельному микрофону, который пришлось бы дополнительно подключать. Всё остальное в статье – это заполнение промежутков между этими двумя идеями, выбор между «строить или покупать» и расчёт стоимости.

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

Рисунок 1. Продакшен-развёртывание. Intake готовит визит, scribe подключается к чистому аудио звонка по говорящему, а подписанная запись отправляется в EHR – с согласием, полученным заранее, и логированием каждого шага.

Продакшен-архитектура, блок за блоком

Реальное развёртывание – это не просто речевая и языковая модель. В каждой системе intake-и-scribe, которую мы разрабатывали, присутствуют восемь типов компонентов, и точное определение их – первая задача любого проекта.

Intake-агент – это входная точка контакта с пациентом. Это разговорная система – чат или голосовой интерфейс, – которая выясняет, с какой проблемой пришёл пациент, и задаёт уточняющие вопросы, как это делает опытный медсестра при первичном опросе. В 2026 году такие системы строятся на языковой модели с чётко прописанным сценарием и жёсткими ограничителями, а их единственный результат – структурированная сводка для врача, но не диагноз для пациента. На этом рынке работают вендоры вроде Paratus Health (основана в 2024 году) и платформа разговорной диагностики Infermedica; Teladoc в 2025–2026 годах перестроил собственный предварительный опрос по тем же принципам. Хорошо спроектированный этап intake заранее заполняет медицинскую карту, а в опубликованных кейсах внедрения сокращает продолжительность визита на пять–десять минут.

Слой видео и захвата – это сам визит и подключение к нему. Звонок работает на стеке WebRTC с selective forwarding unit – медиасервером, или SFU, который маршрутизирует поток каждого участника в групповом звонке. Серверный участник, присоединяющийся к сессии, или хук в SFU захватывает ровно те две аудиодорожки, которые нужны scribe. Этот слой обычно строят на платформе реального времени, а не на сырых сокетах; «строить или купить» для самого звонка – предмет итогового проекта по видеоконференциям.

Слой распознавания речи превращает каждую аудиодорожку в текст с таймкодами. Автоматическое распознавание речи – технология, превращающая речь в текст, сокращённо ASR – здесь должно уметь больше, чем обычная диктовка: точно распознавать названия и дозировки лекарств, раскрывать клинические сокращения и справляться с акцентами. В 2026 году в продакшене предпочтительны движки с медицинской настройкой, такие как Deepgram Nova-3 Medical и модель AssemblyAI Universal с её медицинским режимом, либо самостоятельно развёрнутая модель из семейства Whisper, если данные должны оставаться внутри. Инженерия распознавания речи в продакшене – отдельная тема урока про streaming ASR.

Слой диаризации определяет, кто какие слова сказал. Поскольку видеозвонок уже разделяет участников по отдельным дорожкам, большая часть работы выполняется автоматически, но эти дорожки всё равно нужно выровнять и объединить в единый транскрипт с метками говорящих. WhisperX и Pyannote – стандартные инструменты, подробно рассмотренные в уроке про WhisperX и уроке про Pyannote.

Слой структуризации превращает сырой транскрипт в клиническую запись и для безопасности реализуется в два этапа, а не в один. Сначала модель извлекает клинические факты – симптомы, объективные данные, назначенные лекарства, план обследования и лечения – и привязывает каждый из них к конкретному фрагменту транскрипта, откуда он взят. Затем языковая модель формирует запись на основе этих извлечённых фактов, обычно в стандартном формате SOAP: Subjective (что сообщает пациент), Objective (что наблюдает врач), Assessment (рабочий диагноз, озвученный врачом) и Plan (дальнейшие шаги). Такой порядок – сначала извлечение, потом генерация – позволяет каждой строке итоговой записи проследить до реального высказывания в транскрипте. Ниже мы подробнее объясним, почему именно этот подход делает систему безопасной, а альтернативный – нет.

Слой просмотра и подписи – место, где человек касается всего. Врач читает intake-сводку до звонка и правит её; читает черновик записи после звонка, исправляет неверное и подписывает. Это обычная веб-территория – экран черновика, поле правки, действие подписи, – и она намеренно самая тщательно спроектированная в продукте, потому что это та грань, что делает результат доверенным и законным.

Слой интеграции с EHR помещает подписанную запись в медицинскую карту. Современный подход – FHIR (Fast Healthcare Interoperability Resources, стандартный API медицинских данных), обычно через SMART on FHIR – фреймворк авторизации, позволяющий внешнему приложению запускаться внутри EHR с необходимыми правами. Запись передаётся как ресурс FHIR DocumentReference. У этого блока есть известная ловушка, которую мы подробно разбираем в разделе про продакшен-заботы: наивный вызов приводит к тому, что запись оказывается не в том месте.

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

«Строить или купить»: вердикт 2026 года, компонент за компонентом

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

Две ячейки заслуживают внимания, потому что в 2026 году в них произошли изменения. Выбор распознавания речи теперь – вопрос безопасности, основанный на опубликованных данных, а не на сравнении цен: в заявленных вендором клинических оценках медицинский режим AssemblyAI показал долю пропущенных сущностей 4,97% по медицинским терминам против 7,32% у Deepgram Nova-3 Medical – то есть промахов на треть меньше по словам, критически важным для безопасности пациента. При этом Deepgram в марте 2026 года выпустил обновление Nova-3, снизившее частоту словесных ошибок примерно на треть по языковым данным. Урок: оценивать нужно на вашем аудио и считать ключевым показателем долю промахов по медицинским терминам, а не общую WER.

Сам выбор «строить или покупать» для scribe изменился в феврале 2026 года, когда Epic – EHR, используемая значительной частью больниц США, – представила собственный встроенный фоновый scribe под брендом Art, который автоматически составляет черновики записей и назначений прямо в медицинской карте без привлечения стороннего вендора. Microsoft и Nuance с Dragon Copilot уже доминировали на рынке отдельных решений, за ними следовали Abridge, Ambience Healthcare, Suki и Nabla; выход встроенного варианта от Epic заставил каждую систему здравоохранения задуматься: стоит ли вообще заключать отдельный контракт на scribe. Для продуктовой команды вывод очевиден: если ваши клиенты работают внутри Epic и им нужен лишь базовый scribe, вы соперничаете с бесплатной встроенной функцией. Поэтому шанс на успех – в том, чего Art не делает: ваша специализация, собственный интерфейс для приёма пациентов, контроль над данными, поддержка нескольких EHR или уникальный опыт визита, которым Epic не обладает. Анализ по компонентам речевого и языкового стека – тема урока про streaming ASR и урока про реальную стоимость ИИ.

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

Рисунок 2. Что строить, а что брать. Интегрируйте вызов и стандарт EHR, приобретите или разверните модели, а сами реализуйте логику структуризации, границу доверия и слой соответствия – три компонента, которые действительно и составляют ваш продукт.

Один пациент: от записи на приём до подписанной записи

Числа и блоки обретают конкретику, когда вы проводите одного пациента через систему. Рассмотрим один визит: пациент записывается на телемедицинский приём в эту же неделю из-за упорного кашля.

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

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

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

Черновик записи с прикреплённой сводкой первичного осмотра попадает на экран просмотра и подписи. Врач просматривает его, видит, что каждая строка подкреплена пояснением – откуда она взялась, – исправляет ошибочно распознанную дозировку и подписывает документ. Только после этого выполняется запись в EHR: подписанная версия передаётся в систему в формате FHIR DocumentReference и попадает в нужное место на рабочей поверхности врача, а не в папку с неприкреплёнными документами. Каждый этап – согласие, сбор данных, транскрипт, извлечение фактов, создание черновика, редактирование, подпись и запись – фиксируется в аудит-логе, так что даже спустя недели любой специалист может восстановить, как именно появилась запись в медицинской карте.

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

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

Рисунок 3. Один визит от начала до конца. Машина готовит и формирует черновик; врач проверяет и подписывает; согласие даётся до начала процедуры; каждая строка записи прослеживается до подтверждающих данных.

Проблема точности, вокруг которой следует проектировать

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

Первый – галлюцинация транскрипции, когда речевая модель выдумывает слова, которых на самом деле не произносили. Это не гипотетическая угроза. Исследование 2024 года, представленное на конференции ACM по справедливости, подотчётности и прозрачности, пропустило клинически ориентированное аудио через широко используемую модель OpenAI Whisper и выявило, что около 1% сегментов содержали галлюцинированный текст – выдуманные фразы, а в отдельных случаях – придуманные названия лекарств или потенциально опасные формулировки, которых никто не произносил. На тот момент, по оценкам, Whisper использовали десятки тысяч клиницистов – и вот как доля в 1% превращается в десятки тысяч искажённых транскриптов в масштабах реального применения. Исследователи отметили, что несколько других коммерческих систем такого поведения не проявили – напоминание о том, что выбор ASR-движка – это решение о безопасности. Именно поэтому в таблице «строить или покупать» доля ошибок при распознавании медицинских терминов считается ключевым показателем.

Второй – собственные ошибки языковой модели на стадии структуризации: не только галлюцинации, но и пропуски, когда важная деталь просто исчезает без объяснений. Исследования клинических резюме на языковых моделях показывают, что они находятся в нижних единицах процентов; один анализ зафиксировал около 1,47% галлюцинаций и 3,45% пропусков. Пропуски опаснее галлюцинаций, потому что на странице всё выглядит корректно – факта просто нет, – а пропущенная аллергия или упущенная доза могут иметь гораздо более серьёзные последствия, чем добавленная врачом замеченная фраза.

Третий принцип уникален для «intake»-половины системы: соблазн поручить intake оценку срочности состояния пациента. Софт для проверки симптомов куда менее надёжен, чем может показаться. Независимые исследования показывают, что онлайн-чекеры симптомов дают правильную рекомендацию по срочности лишь примерно в 58% случаев: в 20–30% случаев они чрезмерно осторожны – советуют «ехать в скорую», а в 10–15% – ещё опаснее – недооценивают состояние и рекомендуют отправить пациента домой. Именно эти цифры объясняют, почему в данной системе агент intake ограничен только сбором информации, но не принятием решений: он фиксирует симптомы и передаёт сводку врачу, но никогда не сообщает пациенту, насколько срочно требуется приём. Как только intake начинает определять приоритетность, вы автоматически берёте на себя этот уровень ошибок как риск для безопасности пациента – и, как показано в разделе о соответствии, с высокой вероятностью становитесь регулируемым медицинским устройством.

Инженерный ответ на первые два режима отказа – порядок extract-then-generate из слоя структуризации. Когда модель сначала извлекает структурированные факты с привязкой к конкретным фрагментам транскрипта, а затем на их основе генерирует связный текст, обеспечивается двойная защита: запись становится сложнее сфабриковать, поскольку она строится не на свободных ассоциациях, а на извлечённых доказательствах, и каждая строка может показать врачу, откуда взята информация – это превращает просмотр в анализ, а не в переслушивание. Ответ на третий режим – дисциплина границ плюс грань подписи, предмет следующего раздела.

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

Рисунок 4. Два паттерна безопасности. Сначала извлеките факты с доказательствами, затем сгенерируйте запись; после этого каждый черновик должен пройти подпись врача – это и есть реальный контроль безопасности, а не формальность.

Модель затрат с раскрытой арифметикой

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

Начните с транскрипции. Медицинские ASR-API в 2026 году стоят примерно от нескольких десятых цента до одного цента за минуту аудио. Пятнадцать минут по, скажем, $0,005 за минуту – это:

транскрипция:  15 мин × $0,005/мин = $0,075 за визит

Теперь intake-разговор и генерация записи – оба процесса запускают языковую модель. На этапе intake происходит обмен несколькими тысячами токенов – кусочков текста, которые модель читает и генерирует, – в ходе предварительного диалога; структурирование записи анализирует транскрипт и создаёт SOAP-запись, ещё на несколько тысяч токенов. В сумме это составляет около 10 000–20 000 токенов на оба этапа. При ценах моделей среднего уровня 2026 года такая нагрузка обходится в нижние десятки центов:

intake + запись (LLM):  ~15K токенов × ~$0,000004/токен ≈ $0,06–0,20 за визит

Добавьте стоимость поездки на машине – и она составит около четверти доллара:

компьют на визит:  $0,075 + ~$0,15 ≈ ~$0,23 за визит

Сравните альтернативы в одной и той же единице измерения. Сервис человека-scribe обходится примерно в $2000–4000 в месяц на одного врача, который проводит около 400 приёмов – это около $7,50 за визит. Встроенный scribe-вендор на безлимитном тарифе за $99 в месяц обходится примерно в $0,25 за визит. Постройка на собственных API позволяет сэкономить ещё больше – стоимость падает до нижних десятков центов за визит, поскольку исчезает маржа поставщика, а данные остаются внутри вашей инфраструктуры.

Цифры носят иллюстративный характер и зависят от планов вендоров и цен на токены; важна форма. Любой ИИ-маршрут обходится на один-два порядка дешевле за визит, чем человек-скриб, поэтому выбор между ними определяется не столько стоимостью, сколько тем, кто должен хранить данные пациента, и насколько высокий уровень опыта требуется для визита. Одна оговорка – специально для этой системы: постоянные затраты не равны нулю даже при отсутствии визитов, поскольку инфраструктура звонков и хостинг, соответствующий требованиям HIPAA, работает непрерывно. Эти расходы нужно закладывать как отдельную фиксированную строку в месячный бюджет, независимо от количества визитов. Полный метод расчёта, включая токен-арифметику для шагов языковой модели, – в уроке про реальную стоимость ИИ.

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

Рисунок 5. Экономика на один визит. Любой ИИ-маршрут стоит центы за визит против долларов у человека-scribe; ИИ-маршруты различаются владением данными, а не ценой. Держите фиксированную стоимость хостинга отдельной строкой.

Частая ошибка: позволить машине решать вместо подготовки черновика

Отказ, с которым нас чаще всего просят помочь в клинических ИИ-продуктах, – не слабая модель, а хорошая модель, которой доверили решать, а не готовить черновик. Эти три ошибки повторяются снова и снова, и все они решаются на этапе архитектуры, а не при дообучении.

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

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

Третья – доверять одному ASR-движку только потому, что он хорошо звучал в демо. Распознавание речи, безупречно транскрибирующее чёткую речь основателя, всё равно может пропустить или исказить названия лекарств в реальной консультации с акцентом и перебиваниями, а в медицине искажённое название препарата – это уже инцидент безопасности. Решение – тестировать кандидатов на собственном клиническом аудио, оценивать именно долю ошибок по медицинским терминам и сохранять цепочку доказательств extract-then-generate, чтобы врач мог заметить то, что пропустило распознавание. Относитесь к речевому слою как к компоненту безопасности, а не как к массовому потребительскому продукту.

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

План сборки: пять этапов, ценность на каждом шаге

Вы не строите всё сразу и не следуете порядку, в котором нарисована схема. Вы строите так, чтобы после первого майлстоуна уже был рабочий продукт, а каждый следующий выпуск выходил независимо – это поддерживает проект финансируемым и команду мотивированной.

Майлстоун 1 – scribe поверх вашего существующего звонка. Подключитесь к аудио визита по говорящему, запустите ASR и диаризацию, структурируйте черновик записи через extract-then-generate и покажите его на экране просмотра и подписи. Выпустите возможность для врача завершить визит и получить готовый черновик записи на подпись. Пока без intake и без записи в EHR – только выигрыш в документации, самая желанная функция и фундамент, к которому крепится всё остальное. Если он шаткий, остальное не имеет значения.

Майлстоун 2 – согласие и аудит-лог. Добавьте этап получения согласия на запись звонка и неизменяемый аудит-лог для каждого шага. Именно это превращает рабочее демо в решение, которое приватность-офис больницы одобрит для работы с реальными пациентами. Сделать это сейчас – намного дешевле, чем дорабатывать систему, когда данные уже начнут передаваться.

Майлстоун 3 – запись в EHR. Добавьте интеграцию SMART on FHIR, которая помещает подписанную запись в медицинскую карту как DocumentReference и отображается на рабочей поверхности врача. На этом этапе продукт перестаёт быть вспомогательным инструментом, из которого врач копирует данные, и становится частью основного рабочего процесса электронной карты. Именно здесь сосредоточены основные усилия по интеграции и значительная часть времени, затраченного на сертификацию App Orchard.

Майлстоун 4 – входная дверь intake. Добавьте предварительного разговорного агента, который собирает симптомы, анамнез и принимаемые лекарства в сводку, которую врач подтверждает. Теперь система охватывает весь визит – становится его оболочкой, – а не только часть во время звонка, и переиспользует уже построенные паттерны структурирования и просмотра. Ограничьте его функцией сбора, а не сортировки, с первой строки промпта.

Майлстоун 5 – глубина по специальностям и масштаб. Настройте формат записи и сценарий intake под конкретную специальность, добавьте поддержку нескольких EHR помимо первой интеграции и протестируйте систему на больших объёмах данных. Этот этап идёт последним, потому что он требует больше усилий, но сопряжён с меньшим риском, а к этому моменту у вас уже есть реальный продукт, который поможет клиницистам определиться: какую специальность и какую EHR развивать дальше.

Лестница из пяти этапов, референс-стек, решения «строить или покупать», расчёт затрат на визит и чек-лист соответствия – всё собрано на одной странице в загружаемом blueprint в конце статьи, чтобы команда могла повесить его на стену и следовать по пунктам сверху вниз.

Трудная часть – соответствие и граница устройства

Телемед-система, работающая в демо-режиме, – не продукт, если её незаконно использовать в тех регионах, где находятся ваши пациенты. Между рабочей сборкой и развёртываемой версией системы intake-и-scribe существует четыре ключевых границы, и это важнейшая часть статьи, которую следует прочитать до начала написания кода. Это инженерный контекст, а не юридическая консультация; уточните специфику у квалифицированного юриста для каждого рынка, на котором вы работаете.

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

Вторая грань – HIPAA. Health Insurance Portability and Accountability Act – это закон США, регулирующий конфиденциальную медицинскую информацию, или PHI. Эта система работает с PHI на всех этапах – от ответов при первичном опросе до аудиозаписей визитов, их обработки и передачи в электронную медицинскую карту (EHR), – поэтому любой поставщик услуг в этой цепочке считается «бизнес-партнёром» (business associate) и должен подписать Business Associate Agreement (BAA) до начала работы с реальными пациентами. BAA для scribe и intake не может быть стандартным шаблоном: он должен чётко запрещать использование данных пациентов для обучения или улучшения моделей поставщика, ограничивать обработку только минимально необходимыми данными, предусматривать соответствие требованиям HIPAA Security Rule и гарантировать, что любой субподрядчик, имеющий доступ к аудиоматериалам, также подпадает под действие BAA. Если вы разрабатываете систему самостоятельно, а не приобретаете готовое решение, ответственность за реализацию этих мер лежит на вас.

Третья грань – грань устройства, важнейшее решение о границах во всей сборке. По закону США 21st Century Cures Act 2016 года определённый клинический софт был исключён из определения медицинского «устройства» FDA, а руководство FDA по Clinical Decision Support – обновлённое финальной версией в январе 2026 года – чётко прописывает, где проходит эта грань. Короткая версия для этой системы такова: софт, который документирует решение врача или собирает информацию для того, чтобы врач действовал на её основе, обычно не считается устройством; софт, который принимает или направляет клиническое решение, которое врач не может независимо проверить, – может считаться таковым. Две линии границ, описанные в начале статьи, – это именно то, что держит вас на безопасной стороне: intake-агент, который собирает, но не сортирует данные, и scribe, который документирует, но не ставит диагноз, – являются административными инструментами. В тот момент, когда intake-агент сообщает пациенту его вероятное состояние или scribe утверждает диагноз от своего имени, продукт переходит в категорию регулируемых как software as a medical device – другой, более медленный и куда более дорогой путь. Проектируйте с учётом этой границы ещё до написания промпта, а не после.

Четвёртая грань – прозрачность и EU AI Act – касается любого пациента в Европейском союзе. Согласно Регламенту (EU) 2024/1689, система, напрямую взаимодействующая с человеком, обязана сообщить ему, что он имеет дело с искусственным интеллектом. Высокорисковые системы несут повышенные требования соответствия: управление рисками, техническая документация, ведение логов, человеческий надзор, тестирование точности. Обязанности по прозрачности и требования к высокорисковым системам вступают в силу 2 августа 2026 года. Однако предложение «Digital Omnibus» 2026 года, если будет принято, перенесёт некоторые сроки для автономных высокорисковых систем на конец 2027 года – это движущаяся мишень, которую нужно уточнить к моменту публикации.

Обнадёживает то, что Акт смягчает требования к раскрытию информации в тех случаях, когда вывод ИИ прошёл процесс человеческого просмотра или редакторского контроля, а физическое или юридическое лицо несёт редакторскую ответственность – это и есть суть «грани подписи» в данной конструкции. Та же архитектура, что обеспечивает безопасность инструмента, делает его и более лёгким в регулировании. Полная картина регуляторных требований – тема урока про EU AI Act.

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

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

Рисунок 6. Четыре грани соответствия. Получайте согласие до записи аудио, подписывайте BAA без предварительного обучения, используйте intake и scribe для документирования – вне зоны ответственности устройства – и информируйте пациентов из ЕС об использовании ИИ. Грань подписи смягчает эту последнюю обязанность.

Продакшен-заботы: запись в EHR, наблюдаемость и безопасность

Три ключевые проблемы отделяют прототип от того, что система здравоохранения купит и которому доверится.

Запись в EHR – место, где интеграции тихо проваливаются. Запись передаётся в формате FHIR DocumentReference, но наивный вызов «создать документ» обычно сохраняет её как неприкреплённый документ или в корзину просмотра – не в интерфейс для ведения записей, где врач реально работает. Из-за этого функция кажется сломанной, хотя данные технически дошли. Продакшен-решение запускает приложение внутри визита EHR через SMART on FHIR, формирует DocumentReference с метаданными, которые EHR ожидает, помещает его в рабочий процесс ведения записей врача, сохраняет шаги просмотра и подписи и проходит сертификацию вендора EHR (например, Epic App Orchard). Интегрируйте это решение как полноценную инженерную задачу, а не как финальный вечерний этап – оно действительно заслуживает статуса Майлстоуна 3.

Наблюдаемость означает, что вы понимаете, почему визит прошёл не так, уже после его завершения. Клинические ИИ-системы выходят из строя иначе, чем обычные веб-приложения: пропадает аудиодорожка, речевой движок искажает название лекарства, модель структуризации пропускает аллергию. Вам нужны полные трассировки визита – какие модели были задействованы, сколько времени каждая заняла, каковы были транскрипт и извлечённые факты, что исправил врач – всё это должно собираться централизованно, чтобы поддержка могла точно ответить на вопрос: «Почему эта запись оказалась неверной?» – без догадок, а вы сами могли отслеживать динамику своих правок и ошибок со временем. Это нужно закладывать уже на Майлстоуне 1; аудит-лог из Майлстоуна 2 – его основа, а дорабатывать телеметрию в уже работающем клиническом конвейере – болезненно и рискованно.

Безопасность и минимизация данных начинаются с признания того, что аудиозаписи визитов – одни из самых чувствительных данных, которые может хранить компания. Шифруйте данные пациента при передаче и хранении, обеспечивайте строгий контроль доступа к тем, кто может просматривать intake-обзоры и записи, и храните аудио только столько, сколько необходимо – многие системы удаляют исходную запись после подписания документа, оставляя лишь обработанную версию и аудит-след, что снижает риски и упрощает обсуждение согласия. Для клиентов, работающих в регулируемых условиях, возможность самостийного хостинга всего конвейера, чтобы аудиоданные пациента никогда не покидали их инфраструктуру, часто становится решающим фактором, и данная архитектура это поддерживает: каждый компонент может функционировать внутри периметра, соответствующего требованиям HIPAA. Доменная адаптация клинической модели в рамках этого периметра – тема урока по fine-tuning.

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

Фора Софт разрабатывает видеософт с 2005 года, и телемедицина – одна из наших ключевых вертикалей наряду с видеоконференциями, стримингом, онлайн-образованием и видеонаблюдением. Описанная здесь система – взгляд на WebRTC снизу: чистое аудио по говорящему, перехваченное из звонка, intake-агент, который собирает, а не сортирует данные, шаг структуризации по схеме extract-then-generate, грань между просмотром и подписью, а также запись через FHIR в медицинскую карту – всё это формирует основу телемедицинской работы, которую мы выстраиваем. Порядок сборки компонентов и решения «строить или покупать» для нас – не абстрактная теория, а чек-лист, который мы реально применяем, потому что от него зависит разница между scribe, экономящим врачу час в день, и системой, которая тихо выдаёт неверную дозу. Карта соответствия – тоже часть этого чек-листа: мы интегрируем согласие прямо в интерфейс звонка, подписываем BAA без дополнительного обучения до начала любого реального визита и чётко разделяем роли – оставляем черновик на стороне устройства, а окончательное решение – за врачом. Наша работа сосредоточена в телемедицине и видеоконвейерах реального времени, лежащих в её основе, где чистый звонок и аккуратная грань подписи – не украшение, а ядро продукта.

Ключевые выводы

• Продукт – это оболочка вокруг визита: сбор данных до приёма, автоматическая фиксация в процессе и подписанная запись после.
• Одно правило объединяет обе фазы: модель создаёт черновик, решение принимает врач, ничего не отправляется автоматически.
• При видеовизите обеспечивается чистое аудио по каждому говорящему – телемедицина – идеальная среда для scribe.
• Сначала извлекайте факты с привязкой к фрагментам транскрипта, затем генерируйте запись; просмотр превращается в проверку.
• Ограничьте intake сбором информации, а scribe – документированием: пересечение этих функций делает систему устройством.
• Четыре аспекта должны быть решены до запуска: согласие на запись, BAA без обучения, статус устройства и раскрытие использования ИИ в ЕС.

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

• Урок 9.3 – Разработка телемедицинских приложений: инженерный плейбук AI-SCRIBE
• Урок 3.1 – Потоковая ASR в продакшене: Deepgram, Whisper, AssemblyAI
• Урок 6.9 – Живые субтитры: паттерн SFU-стороннего fan-out ASR