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

TL;DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Intake-агент – это входная дверь к пациенту. Это разговорная система – чат или голос, – которая спрашивает пациента, с чем он пришёл, и задаёт уточнения по его ответам, как это делает хороший сестринский 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 не делает: ваша специализация, ваша intake-дверь, ваш собственный периметр данных, мульти-EHR-продукт или опыт визита, которым Epic не владеет. Покомпонентное рассуждение по речевому и языковому стеку – предмет урока про streaming ASR и урока про реальную стоимость ИИ.

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

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

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

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

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

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

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

Черновик записи с прикреплённой intake-сводкой пациента попадает в экран просмотра и подписи. Врач читает его, видит каждую строку подкреплённой словами, откуда она взялась, исправляет неверно расслышанную дозировку и подписывает. Только теперь выполняется запись в 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 садится на компьют-пол выше – нижние десятки центов – с убранной маржой вендора и данными, оставшимися внутри вашего периметра.

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

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

Рисунок 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 между рабочей сборкой и развёртываемой стоят четыре грани, и это важнейшая часть статьи для чтения до написания кода. Это инженерно-релевантный контекст, а не юридическая консультация; уточняйте специфику с квалифицированным юристом для каждого рынка, где вы работаете.

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

Вторая грань – HIPAA. Health Insurance Portability and Accountability Act – закон США, регулирующий защищённую медицинскую информацию, или PHI. Эта система обрабатывает PHI на каждом этапе – ответы intake, аудио визита, запись и запись обратно в 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-сводки и записи, и держите аудио не дольше, чем нужно – многие конструкции удаляют сырую запись после подписи записи, оставляя только запись и аудит-след, что и снижает риск, и облегчает разговор о согласии. Для клиентов в регулируемых условиях self-host всего конвейера, чтобы аудио пациента никогда не покидало их инфраструктуру, часто решающий фактор, и эта архитектура его поддерживает: каждый компонент здесь может работать внутри HIPAA-eligible периметра. Доменная адаптация клинической модели внутри этого периметра – предмет урока про fine-tuning.

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

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

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

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

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

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