Главное
• ИИ-скрайб (AI scribe) — главное прорывное приложение медицинского ИИ в 2026 году. Abridge привлек 22 млрд ₽ в раунде Series D, Suki и Nuance DAX (Microsoft) масштабировались до десятков тысяч клиницистов, а амбиентное документирование — редкая категория ИИ, в которой возврат инвестиций на одного пользователя окупается уже в первый месяц.
• Архитектура состоит из семи этапов, а не одной модели. Захват аудио → диаризация → медицинский ASR → LLM с клиническим RAG → генерация SOAP → подсказка кодов CPT/ICD-10 → запись в EHR. Пропустите любой этап — и продукт не удастся внедрить.
• HIPAA — задача сложнее, чем сам ИИ. BAA на каждом узле, поддержка аудиоданных у облачных LLM (OpenAI Realtime API в 2026 году ещё не покрывается большинством BAA — проверьте перед запуском), шифрование при передаче и в состоянии покоя, неизменяемость логов аудита и чёткий путь удаления, согласованный с правилом шестилетнего хранения.
• Три жизнеспособных экономических сценария. Купить Abridge / Suki / DAX (~15–30 тыс. ₽ на клинициста в месяц, самый быстрый путь к запуску, данные передаются вендору). Создать white-label-решение на партнёрской основе (~6–12 тыс. ₽ на клинициста в месяц, быстрый старт, но меньше контроля). Разработать собственное решение (12–20 недель разработки, 30–105 млн ₽, ~1 875–4 500 ₽ на клинициста в месяц на эксплуатацию, полный контроль над данными и интеллектуальной собственностью).
• Главное преимущество — сэкономленное время, а не идеальная точность текста. Хороший ассистент экономит врачу 60–120 минут в день на оформлении карт после смены. Старайтесь сократить время от остановки записи до появления черновика заметки в системе EHR до 90 секунд, а не гонитесь за минимальными показателями ошибки распознавания, к которым привыкли.
Почему Фора Софт написала этот плейбук
Фора Софт уже два десятилетия разрабатывает телемедицинские и клинические платформы, соответствующие требованиям HIPAA. Мы создали и продолжаем поддерживать CirrusMED — платформу первичной телемедицинской помощи в США, работающую в рамках программы HIPAA с соглашением о обработке защищённой информации (BAA) на всех уровнях. Также мы разработали TransLinguist — платформу видеоперевода для медицинских консультаций, внедрённую в британский NHS, и систему телефонного перевода для больниц, действующих в регулируемых трастах. Захват аудио в клинических условиях, цепочки BAA, границы шифрования при передаче данных, интеграция с электронными медицинскими картами через FHIR и UX-решения, обеспечивающие соблюдение норм, — всё это области, в которых мы уже реализовали готовые продукты.
В 2025–2026 годах мы провели технический due diligence двух стартапов в области AI-SCRIBE на стадии pre-Series A и разработали расширение для автоматического документирования в рамках существующего телемедицинского продукта. Шаблоны в этом руководстве взяты из этих проектов, а также из открытых источников: продуктовых раскрытий Abridge, Suki и Nuance DAX, документации OpenAI Realtime API и их позиции по BAA, технического брифа AWS HealthScribe и рекомендаций AMA / AMIA по использованию ИИ в клиническом документировании.
Если вы — основатель телемедицинского сервиса, внедряющего автоматическое ведение документации, CIO больницы, оценивающий решения вроде Abridge, Suki или DAX, руководитель AI-стартапа в здравоохранении, выбирающий между самостоятельной разработкой и партнёрством, или поставщик EHR, изучающий встроенный ассистент для ведения записей, — это руководство предлагает вам архитектуру, соответствие требованиям HIPAA, расчёты эффективности на одного врача и план запуска за 16–20 недель, который мы применяем у своих клиентов.
Строите кастомный ИИ-скрайб под конкретную специальность?
Бесплатное 30-минутное обсуждение по определению объёма работ. Мы оценим масштаб задач, составим список поставщиков с подписанными соглашениями о конфиденциальности (BAA), подготовим план на 16 недель и предоставим проверенные шаблоны соответствия HIPAA в стиле CirrusMED, которые уже используем в продакшене.
Почему ИИ-скрайб — главное killer-приложение медицинского ИИ в 2026
У медицинского ИИ было шумное десятилетие пилотных проектов, которые так и не перешли в массовое применение. В 2024–2025 годах амбиентное документирование изменило эту ситуацию: здесь ROI стал особенно очевидным. Клиницист тратит 1–2 часа каждый вечер на «ночную» дописку карт после последнего пациента — это время возвращает автоматический ассистент. Net Promoter Score у врачей, использующих Abridge, Suki или DAX, держится в диапазоне +60…+80 — показатель, редкий даже для корпоративного ПО, не говоря уже о здравоохранении.
Категорию вытолкнули в центр три структурных сдвига. Первый — LLM класса GPT в 2023–2024 годах сделали медицинскую суммаризацию достаточно надёжной для черновика заметки. Второй — вендоры EHR (Epic, Oracle Health, athenahealth) построили дружелюбные к скрайбам API записи, потому что этого потребовали системы здравоохранения. Третий — плательщики и CMS негласно приняли заметки, сгенерированные ИИ, как документацию официального уровня, при условии, что клиницист их проверяет и подписывает.
Реакция рынка оказалась резкой. Abridge — 22 млрд ₽ в Series D в 2024 году. Suki и DAX (Microsoft) масштабируются на тысячи систем здравоохранения. Heidi, Augmedix, Doximity, Nabla, Freed, ScribeAmerica — все запускают свои версии продукта. Поэтому в 2026 году вопрос «строить или покупать» становится актуальным для каждого CIO системы здравоохранения, каждого основателя телемедицинского сервиса и каждого поставщика EHR.
Что такое ИИ-скрайб на самом деле
ИИ-скрайб — это не просто инструмент для расшифровки речи. Это сквозной пайплайн, который обрабатывает разговор врача с пациентом — как в кабинете, так и при телемедицине — и создаёт структурированную клиническую заметку (обычно по формату SOAP: Subjective, Objective, Assessment, Plan), подсказывает коды для выставления счётов и сохраняет результат в электронную медицинскую карту на проверку и подпись врача.
1. Это амбиентный продукт. Клиницист не диктует. Микрофон работает фоном на всём протяжении приёма. Записываются оба собеседника. Модель должна извлекать клинические факты из разговора, а не из структурированной диктовки.
2. Это структурированный вывод. На выходе не просто текстовый абзац транскрипта. Это SOAP-заметка — в том виде, в котором реально читают медицинскую карту: Chief Complaint, History of Present Illness, Review of Systems, Physical Exam, Assessment, Plan и инструкции пациенту. У каждой секции — свой стиль и объём.
3. Это продукт, понимающий биллинг. Ценный скрайб также подсказывает коды CPT и ICD-10 на основе контекста разговора (а не просто по ключевым словам). Клиницист проверяет подсказки; revenue cycle экономит время и повышает точность.
4. Это интегрированный продукт. Клиницисту не нужно копировать и вставлять данные вручную. Заметка автоматически возвращается в Epic, Cerner, athena или любой другой EHR — через FHIR, HL7v2 или API конкретного вендора. Без интеграции продукт становится просто инструментом для повышения продуктивности, но не решает реальных задач.
5. Это продукт уровня HIPAA. Аудиозаписи становятся защищённой медицинской информацией (PHI) сразу после записи. Весь пайплайн работает в рамках соглашения о обработке данных (BAA), обеспечивает шифрование при передаче и в состоянии покоя, ведёт аудит-логи, а также поддерживает управление согласием пациента — включая его отзыв.
Семистадийная референсная архитектура
Каждый выпущенный в 2026 году скрайб — Abridge, Suki, DAX, Heidi, Nabla, AWS HealthScribe, наши кастомные сборки — строится по одному и тому же семиступенчатому пайплайну. Различаются реализации, вызовы к вендорам и место оркестрации. Форма остаётся неизменной.
Следующие разделы подробно описывают каждую стадию. Они расположены в том порядке, в котором аудио проходит путь — от захвата до записи в EHR, — чтобы решения на каждой стадии принимались с учётом предшествующих и последующих этапов.
Стадия 1 — Захват аудио и инфраструктура, соответствующая требованиям HIPAA
Захват аудио — это отправная точка для соблюдения HIPAA. Есть два сценария: очные приёмы (приложение для iOS / Android, десктопный хелпер, USB-микрофон с beamforming) и телемедицинские приёмы (интеграция в WebRTC-поток). Для очных приёмов лучше использовать микрофон с beamforming — например, серию Shure MXA или USB-микрофон за 2 250 ₽ от поставщика клинического оборудования. Такой микрофон подавляет посторонние голоса, шум вентиляции и стук по клавиатуре. В телемедицине аудио нужно захватывать на стороне ингеста — после обработки эхоподавления, но до смешивания потоков.
Кодек и частота дискретизации важны для работы ASR. 16 кГц моно PCM (или 16 кГц Opus на 32–64 кбит/с) — оптимальный выбор. Ниже 16 кГц качество распознавания медицинских терминов начинает падать; выше — просто тратится пропускная способность, особенно при использовании телефонных микрофонов.
Инфраструктура должна быть полностью совместима с HIPAA. Используйте регион AWS / GCP / Azure, в котором у провайдера есть подписанное соглашение о обработке данных (BAA), соответствующее HIPAA. Шифруйте аудиофайлы в состоянии покоя с помощью ключей KMS, управляемых провайдером. Обеспечьте шифрование при передаче по протоколу TLS 1.2 или выше. Храните необработанное аудио только до тех пор, пока оно необходимо (большинство компаний удаляет его в течение 30 дней; некоторые держат дольше — только с явного согласия пациента и для дообучения моделей). Аудио относится к защищённой медицинской информации (PHI), поэтому все хранилища — bucket, topic, queue — должны рассматриваться как носители PHI целиком.
Берите микрофон с beamforming, когда: приёмы проходят очно, кабинет шумный или клиницист двигается по кабинету во время визита. Только-телемедицинские сценарии могут обойтись без него.
Стадия 2 — Диаризация спикеров
Диаризация отвечает на вопрос: «Кто, что и когда сказал». В большинстве случаев спикеров двое — клиницист и пациент, но на реальных приёмах могут присутствовать родственники, опекуны, переводчики и медицинский ассистент. Готовые инструменты: pyannote.audio (золотой стандарт офлайн-диаризации), встроенная диаризация AWS Transcribe Medical, NVIDIA NeMo и API диаризации AssemblyAI.
Полезный паттерн — диаризовать дважды. Онлайн, в реальном времени, быстрой моделью (точность ниже, нужна для живого интерфейса, показывающего, кто сейчас говорит). Офлайн, после визита, — pyannote или NeMo на полном аудио (точность выше, результат идёт в LLM). Стоимость двойного прохода невелика, а точность офлайн-обработки влияет на качество заметки сильнее, чем точность распознавания речи.
Берите офлайн-передиаризацию, когда: качество заметки важнее задержки интерфейса, в визите участвуют более двух спикеров или правки клиницистов после визита связаны с ошибочной атрибуцией спикеров.
Стадия 3 — ASR с медицинским контекстом
Медицинский ASR — место, где универсальные транскрипционные инструменты дают сбой. Названия препаратов, дозировки, анатомические термины, сокращения, лабораторные показатели и названия процедур — всё это длинный хвост словаря, по которому стандартный ASR будет гадать. В 2026 году жизнеспособные варианты: AWS Transcribe Medical, Microsoft Azure Healthcare Speech, медицинская модель AssemblyAI, Deepgram Nova-2 medical, NVIDIA Parakeet-MED и самостийный Whisper с клиническим лексиконом и доменно настроенным beam-search-рескорером.
Word error rate — плохой показатель эффективности для медицинского распознавания речи сам по себе. Настоящий KPI — полнота распознавания медицинских сущностей: удалось ли системе определить название препарата, дозировку, способ введения, частоту приёма? Распознал ли она анатомический термин или название процедуры? Правильно ли зафиксировано состояние с кодом ICD-10? Соберите тестовый набор из 200–500 фрагментов приёмов и измеряйте полноту распознавания сущностей по каждой медицинской специальности.
Растущий паттерн — подавать LLM неочищенный транскрипт ASR вместе с эмбеддингом аудио (или его низкобитным представлением). LLM может исправлять ошибки распознавания, используя контекст, недоступный для простого текстового постобработки. Этот подход применяют AWS HealthScribe и некоторые кастомные решения; в наших тестах он повышает полноту распознавания сущностей на 4–8 процентных пунктов.
Берите self-hosted Whisper, когда: важна резидентность данных, нужен полный контроль над моделью или покрытие BAA у вендора в нужном облачном регионе неполное.
Стадия 4 — LLM с клиническим RAG
LLM — мозг скрайба. Она берёт диаризованный, прошедший ASR транскрипт и формирует шаги клинического рассуждения, превращая разговор в структурированную заметку. В 2026 году жизнеспособные варианты LLM (под BAA): Anthropic Claude в AWS Bedrock в HIPAA-совместимом регионе, модели класса GPT-4 в Azure OpenAI под healthcare-версию BAA от Microsoft, Google Gemini в Vertex AI в HIPAA-совместимом регионе и self-hosted-модели на открытых весах (класса Llama-3, Mistral, производные MedAlpaca) для заказчиков со строгими требованиями к резидентности данных.
Клинический RAG — ключевой фактор, превращающий универсальный суммаризатор в полезного ассистента. Каждая сгенерированная заметка должна опираться на: предыдущую карту пациента (список проблем, аллергии, лекарства, прошлые записи), предпочтительные шаблоны врача (заметка при дерматологическом осмотре и приём в акушерстве выглядят по-разному), актуальные клинические рекомендации по основной жалобе и формуляр клиники. RAG, работающий с видео, аудио и чатом, использует ту же структуру; клинический RAG просто строже проверяет происхождение информации.
Стадия 5 — Генерация SOAP-заметки
Формат SOAP — Subjective, Objective, Assessment, Plan — это стандартный способ структурировать клиническую записку в амбулаторной практике в США. У каждой части свои особенности. В разделе Subjective — краткое повествование («пациент сообщает…»). В Objective — краткие пункты с результатами осмотра. В Assessment — нумерованный список дифференциального диагноза. В Plan — нумерованный перечень действий: назначение лекарств, дозировки, сроки повторного приёма и разъяснения для пациента.
Генерируйте четыре секции поочерёдно — четырьмя отдельными проходами LLM, а не одним большим запросом. У каждого прохода — свой системный промпт, свой набор данных для поиска и свой лимит длины. Такой подход снижает количество ошибок, делает тестирование изменений по частям более управляемым и позволяет клиницисту редактировать одну секцию, не нарушая другие. Отдельный проход «patient- facing summary» создаётся для информационных материалов с кратким резюме визита.
Берите четырёхпроходный паттерн SOAP, когда: галлюцинации в одно-промптной базовой реализации превышают 1 %, правки клинициста сосредоточены в одной секции (обычно Plan) или специализированные шаблоны требуют строгого посекционного форматирования.
Стадия 6 — Подсказка кодов CPT и ICD-10
Кодирование — это место, где скрайб получает вторую часть ROI. Подсказывайте коды CPT (процедура / уровень визита E&M) и ICD-10 (диагноз) на основе контекста приёма. Не выставляйте счета автоматически: клиницист или кодировщик должен проверить и подтвердить выбор. Команды по управлению доходами в больницах принимают кодирование с ИИ-подсказками только при наличии оценки уверенности и цитаты из фрагмента разговора, которая обосновывает выбранный код.
Соберите кодировщик как шаг LLM, который на вход получает SOAP-заметку и диаризованный транскрипт, а на выходе выдаёт список кортежей (код, обоснование, фрагмент, уверенность). Закэшируйте справочники AMA CPT и CMS ICD-10 в индексе RAG. Перезапускайте кодировщик при каждом изменении заметки, чтобы подсказанные коды учитывали правки клинициста.
Стадия 7 — Запись в EHR
Запись в EHR — ключевой фактор успеха или провала внедрения. Три подхода. 1. Запись через FHIR (Epic, Oracle Health/ Cerner, athenahealth — все предоставляют ресурсы FHIR R4 DocumentReference и Encounter для фиксации заметок, всё чаще без отдельного проекта интеграции на стороне заказчика). 2. HL7v2 (устаревшие системы по-прежнему используют сообщения ORU и MDM поверх MLLP). 3. Вендорские REST API (Epic App Orchard / Showroom, Oracle Health Code Console, маркетплейс API athenahealth) — более глубокие возможности, но больше работы на каждого поставщика.
Планируйте время от остановки записи до появления черновика заметки в worklist EHR не более 90 секунд. Если процесс займёт дольше — клиницист, скорее всего, перезапустит систему вместо того, чтобы ждать. Заранее кэшируйте контекст пациента (список проблем, лекарства, аллергии, недавние визиты), чтобы обработка LLM начиналась сразу после остановки записи.
Реальность HIPAA — аудиомодальность и цепочки BAA
Каждый внешний сервис, работающий с аудио или транскриптом, должен быть подписан по соглашению Business Associate Agreement (BAA). Цепочка безопасности ломается на самом слабом звене. К 2026 году большинство крупных платформ стали кооперативными: AWS, GCP, Azure, AssemblyAI, Deepgram, AWS HealthScribe, Anthropic в Bedrock, Microsoft Azure OpenAI — все они подписывают BAA. Но есть исключения, на которые стоит обратить внимание: аудиомодальность OpenAI Realtime API в 2026 году ещё не покрыта большинством BAA (компания работает над этим; перед использованием в клинической среде обязательно проверьте актуальную версию соглашения). Прямые потребительские голосовые сервисы, такие как ElevenLabs и публичные эндпоинты Whisper API, как правило, не имеют BAA.
Неизменяемость аудит-лога имеет значение. Append-only-логи (CloudTrail с S3 Object Lock, Azure Monitor в неизменяемом режиме, Google Cloud Audit Logs в compliance-режиме) — это операционный ответ. Храните логи как минимум 6 лет, чтобы соответствовать требованиям HIPAA.
Удаление пациента — нетривиальная задача. Отзыв согласия пациентом должен привести к удалению аудиофайла, транскрипта и всех артефактов обучения модели, при этом клиническая заметка, подписанная специалистом, остаётся сохранённой (это медицинская запись, подлежащая хранению по закону штата — обычно 6–10 лет). Стройте граф данных так, чтобы аудио ↔ транскрипт ↔ подсказанные коды ↔ подписанная заметка были индивидуально адресуемы для удаления.
Abridge vs Suki vs Nuance DAX vs кастомное решение
Большинство сравнений сводится к четырём сторонам. Ответ зависит от контроля над данными, глубины интеграции с EHR, соответствия специальности и бюджета. Цены и функционал меняются от квартала к кварталу; таблица ниже — снимок по публичным материалам и разговорам с операторами на начало 2026 года.
| Вариант | Ценовой диапазон | Интеграция с EHR | Контроль данных | Специализации |
|---|---|---|---|---|
| Abridge | ~15–30 тыс. ₽ / клиницист / мес. | Глубокая Epic, Oracle, athena | Хостится у вендора | Сильны в первичной помощи, расширяют спектр |
| Suki | ~11–22 тыс. ₽ / клиницист / мес. | Epic, athena, eClinicalWorks | Хостится у вендора | Мультиспециальность, сильны в кардио / орто |
| Nuance DAX (Microsoft) | ~22–45 тыс. ₽ / клиницист / мес. | Нативная Epic, Cerner / Oracle | Хостится у Microsoft | Широкий спектр, акцент на энтерпрайз |
| AWS HealthScribe | По потреблению — около 7–22 ₽ в минуту | DIY (собираете сами) | Ваш аккаунт AWS | Универсальный, специализацию настраиваете сами |
| Кастомная сборка (паттерн Фора Софт) | ~1 875–4 500 ₽ / клиницист / мес. эксплуатации + 30–105 млн ₽ на разработку | Ваш стек, ваши приоритеты | Ваше облако, ваши BAA | Любая, на которую вы дообучаетесь |
Два вывода. Первый: покупка готовых решений от вендоров для одного клинициста экономически оправдана для больниц со стабильным бюджетом, но нецелесообразна для телемедицинских платформ, которые платят такую же сумму за каждого специалиста в своей сети. Второй: собственная разработка окупается, если у вас либо (а) более 600 клиницистов, либо (б) узкая специализация, которую вендоры не поддерживают, либо (в) жёсткие требования к хранению данных на территории страны.
Дообучение под специальность — кардиология, дерматология, акушерство и гинекология
Универсальный скрайб уверенно справляется с заметками в стиле первичной помощи. У каждой специальности — свои словарные запасы, структуры и способы кодирования. Кардиологические записи опираются на результаты стресс-тестов, данные ЭКГ, фракцию выброса и терминологию кардиохирургических процедур. В дерматологии важны описания кожных элементов, планы биопсий и ограниченный набор CPT-кодов (серия 17000). В акушерстве и гинекологии фиксируют акушерский анамнез (по системе G/Р), результаты УЗИ и учитывают быстро меняющийся правовой контекст после решения по делу *Dobbs*, влияющий на клиническое документирование.
Прагматичное дообучение под специальность — это два этапа. На первом этапе используется доменный индекс RAG: корпус специализированных гайдлайнов, клинические заметки по той же специальности с кодами, шаблоны. На втором — небольшое SFT на нескольких тысячах заметок, отредактированных клиницистами в этой области. Полный LoRA или полный файнтюнинг базовой LLM обычно не требуются и редко окупаются; подход «RAG плюс шаблоны» даёт основную часть прироста.
Модель затрат — экономика на одного клинициста
У кастомного скрайба три статьи затрат: разработка, эксплуатация и операции. Разработка — это 16–20-недельный инженерный цикл, стоимостью 30–105 млн ₽. Цена зависит от количества специальностей, глубины интеграции с EHR и того, начинаете ли вы с уже готовой части пайплайна. Эксплуатация включает стоимость инфраструктуры на визит: ASR — около 3 ₽ в минуту, токены LLM — 3–7,5 ₽ за заметку, инфраструктура и мониторинг — примерно 1,5 ₽ на визит, плюс амортизация коннектора EHR. Типичный день клинициста с 18 визитами обходится в 67–135 ₽ на сырой инфраструктуре. Если округлить на пятидневную рабочую неделю и 48 рабочих недель в году, то ежемесячные расходы на одного клинициста составляют около 1 875–4 500 ₽.
Операции — это человеческая работа по поддержанию модели в рабочем состоянии: небольшая команда clinical-ai разбирает сложные случаи, дообучает модули по специальностям, отслеживает частоту ошибок и принимает решения по запросам пациентов на удаление данных. Закладывайте одного клинического инженера на 2000 клиницистов в стационарном режиме и part-time-ревьюера с медицинским образованием.
Системам здравоохранения, сравнивающим стоимость покупки Abridge (15–30 тыс. ₽ / клиницист / мес.) и полную стоимость кастомной сборки (3 375–6 000 ₽ / клиницист / мес. при масштабировании), точка безубыточности — около 600 клиницистов. Меньше — выгоднее покупать. Больше — обычно выигрывает кастомная сборка, особенно если важны контроль над данными и возможность получить выгодные условия на общей инфраструктуре.
Поток согласия пациента
Согласие пациента — это то, что он видит, и то, что проверяет регулятор. Создайте понятный интерфейс, в котором пациенту чётко объясняют: (а) что именно записывается, (б) зачем это нужно, (в) кто может получить доступ, (г) как долго данные хранятся и (д) как отозвать согласие. Формулировки должны быть короткими и простыми: «Этот визит записывается, чтобы врач мог лучше вас выслушать». Юридические детали — в политике конфиденциальности и BAA, а не в интерфейсе согласия.
В штатах с правилом одностороннего согласия (большинство штатов США) юридически достаточно согласия клинициста, но любой ответственный скрайб всё равно уточняет мнение пациента — ведь успех внедрения зависит от его комфорта. В штатах с двусторонним согласием (Калифорния, Флорида, Иллинойс, Мэриленд, Массачусетс, Монтана, Невада, Нью-Гэмпшир, Пенсильвания, Вашингтон по состоянию на 2025 год) явное согласие пациента обязательно; без него запуск невозможен.
Мини-кейс — слой скрайба в стиле CirrusMED
Телемедицинский оператор, использующий инфраструктуру в паттерне CirrusMED, попросил нас добавить амбиентный скрайб поверх существующего продукта видеовизитов. У них работало около 220 клиницистов в первичной помощи и поведенческом здоровье, была интеграция с athenahealth и собственным внутренним EHR, а аудио они хотели хранить в своём аккаунте AWS.
Мы выпустили решение за 17 недель. Стек: AWS Transcribe Medical для распознавания речи, pyannote.audio для офлайн-предваризации, Anthropic Claude в Bedrock для четырёхпроходной генерации SOAP и подсказок по CPT / ICD-10, индекс RAG в OpenSearch с предыдущей картой, списком проблем и шаблонами клиницистов, запись через FHIR DocumentReference в athena и кастомный путь HL7v2 во внутренний EHR. Согласие пациента добавлено как в предвизитный поток, так и на экран во время визита.
По итогам первого квартала: средняя «ночная» дописка карт сократилась с 1 ч 48 мин до 22 мин на клинициста в день, NPS клиницистов по скрайбу — +71, объём правок заметок постепенно снижался по мере внедрения специализированных дообучений, а команда по работе с доходами оператора принимала ИИ-подсказки по кодированию в 84 % визитов без дополнительной доработки кодировщиком. Хотите аналогичный проект? Позвоните или напишите нам.
Нужен ИИ-скрайб, совместимый с HIPAA, за 16 недель?
Бесплатное 30-минутное обсуждение по определению объёма работ. Мы подготовим список поставщиков с подписанными соглашениями о защите данных (BAA), пошаговую архитектуру, модель затрат на одного клинициста и план внедрения.
Фреймворк решения в пяти вопросах
Пройдите пять вопросов ниже, прежде чем выбрать «строить», «купить» или «партнёриться». Ответы помогут определить, какая полоса вам подходит.
1. Сколько клиницистов? Меньше ~250 — покупайте Abridge или Suki и запускайтесь за несколько недель. От 250 до 600 — рассмотрите AWS HealthScribe с небольшим кастомным слоем или партнёрской моделью. Больше 600 — кастомная разработка обычно выгоднее по TCO за 24 месяца.
2. Какой состав EHR? Все площадки на Epic могут позволить себе глубоко интегрированного вендора — Abridge или DAX. Гетерогенный состав EHR вынуждает использовать кастомную сборку или комбинацию HealthScribe с кастомным решением, потому что уровень поддержки вендоров в разных EHR-системах сильно различается.
3. Какие специальности? Первичная помощь — вендоры сильны. Поведенческое здоровье — вендоры слабее, кастом окупается. Хирургия, акушерство и гинекология, кардиология — зависит от вендора; пилотируйте на небольшой группе, прежде чем брать на себя обязательства.
4. Где живёт аудио? Если ваши контракты запрещают аудио покидать ваш аккаунт в облаке или вашу страну — кастом — единственный путь. Вендорские решения обрабатывают аудио в облаке вендора; для части систем здравоохранения и большинства государственных заказчиков это — критичное препятствие.
5. Какова ваша AI-ops-ёмкость? Кастомному скрайбу нужна небольшая команда по клиническому ИИ. Если такой команды нет и собрать её не получается, сотрудничество с разработчиком, у которого этот опыт уже есть (мы — один из таких), безопаснее, чем создавать команду с нуля и терять год.
Чего избегать
1. Оптимизировать WER вместо сэкономленных минут клинициста. Скрайб с WER 6 % и round-trip 30 секунд побеждает скрайб с WER 4 % и round-trip 4 минуты в любом опросе клиницистов. Оптимизируйте время до черновика, а не качество транскрипта.
2. Пропустить аудит BAA. Считайте каждый внешний сервис в пайплайне (ASR, LLM, наблюдаемость, log-shipper, даже sentry-стильный крэш-репортер) касающимся PHI, пока не доказано обратное. Пройдите цепочку BAA от начала до конца до запуска.
3. Один гигантский промпт вместо многопроходного пайплайна. Скрайбы на одном промпте ошибаются, выдают вымышленные данные и портят форматирование разделов. Генерируйте Subjective, Objective, Assessment, Plan и patient-summary как отдельные этапы — с отдельным поиском информации, своими промптами и лимитами по длине.
4. Забыть про штаты с двусторонним согласием. Сделать одинаковый UX согласия пациента в Калифорнии и Техасе, потому что так проще с технической точки зрения, — быстрый способ получить иск в Калифорнии. Матрицу согласий по штатам нужно внедрять с самого начала.
5. Считать запись в EHR пунктом из Phase 5. Если записи в EHR нет в MVP — продукт никогда не выйдет в прод, потому что клиницисты не примут ничего, что требует копипасты. Планируйте запись в EHR как Phase 1, а сужение объёма — как Phase 5.
KPI, которые стоит измерять
KPI качества. Точность распознавания медицинских сущностей — более 96 % по ключевым категориям (препараты, дозы, анатомия, кандидаты ICD-10), соответствие форматированию разделов — выше 99 % (форма SOAP проходит проверку lint), частота галлюцинаций — менее 0,4 % сгенерированных заметок, объём правок клинициста постепенно снижается с каждым кварталом.
Бизнес-метрики. Сокращение «ночной» дописки карт более чем на 60 % на клинициста, время до черновика — менее 90 секунд с момента остановки записи, NPS клиницистов выше +50 в первый месяц, принятие ИИ-кодирования — более 80 % без правок кодировщика, отток — ниже 5 % за квартал.
KPI надёжности. Доступность пайплайна — выше 99,95 % в рабочие часы клиники, p99 round-trip — меньше 120 секунд, успешность записи в EHR — выше 99,5 %, чистый аудит цепочки BAA — каждый квартал, выполнение запросов на удаление — не более 7 дней с момента обращения пациента.
FAQ
Abridge vs Suki vs Nuance DAX — что выбрать?
Если вы используете all-Epic-систему первичной помощи и вам нужна самая глубокая нативная интеграция — выбирайте Abridge или DAX. Если у вас мультиспециальность и важен удобный, быстрый интерфейс для врачей — Suki. Если вы уже работаете в экосистеме Microsoft — DAX будет оптимальным выбором по умолчанию. Ни один из этих вариантов не решает задачи строгой резидентности данных или узкой специализации; для таких случаев требуется кастомное решение.
Подходит ли OpenAI Realtime API под HIPAA для амбиентного скрайба?
По состоянию на начало 2026 года аудиомодальность Realtime API пока не поддерживается большинством BAA, даже у тех клиентов, у которых есть BAA на стандартный текстовый эндпоинт. Перед использованием продукта с Realtime audio в клинике уточните актуальные условия BAA у вашего аккаунт-менеджера. В 2026 году безопаснее использовать Anthropic Claude через AWS Bedrock или Azure OpenAI с их healthcare-совместимыми BAA.
Сколько занимает разработка кастомного ИИ-скрайба?
Сфокусированный MVP с одной специальностью, одним целевым EHR и одним облачным LLM — 12–14 недель. Мультиспециальный скрайб, работающий с несколькими EHR, с полной программой соответствия HIPAA и UX для получения согласия пациента — 16–20 недель. К этому добавьте 4–6 недель на любой кастомный файнтюнинг. Программа обеспечения соответствия HIPAA реализуется параллельно и сама по себе занимает 6–8 недель.
Нужен ли файнтюнинг или хватит RAG?
Для большинства задач — нет. Хороший клинический индекс RAG (специализированные руководства, шаблоны врача, данные пациента) в сочетании с грамотной настройкой промптов на передовых LLM (Claude, GPT-4, Gemini) даёт 90% нужного результата. Файнтюнинг окупается только тогда, когда у вас очень специфические паттерны или строгий стиль, который RAG не может надёжно воспроизвести.
Может ли скрайб заменить человека-скрайба?
Да — для документирования; пока нет — для управления работой в кабинете, которую выполняют опытные люди-скрайбы. Большинство операторов рассматривают ИИ-скрайб как инструмент для клинициста, чтобы избежать дописки карт дома, а не как замену человеку в каждом кабинете. Некоторые системы здравоохранения уже переводят людей-скрайбов на роли координаторов помощи.
А что с визитами на неанглийском языке?
Многоязычный скрайб сложнее. Либо ведите визит с поддержкой переводчика (мы это делали на TransLinguist для NHS) и пишите английскую сторону, либо используйте многоязычный ASR (AWS Transcribe и Whisper-large-v3 хорошо работают на испанском; ниже уверенность на мандарине / вьетнамском / тагальском). Дообучение под специальность на не-английских языках разрежено; готовьтесь к большему объёму правок клинициста.
Как используются данные пациента для дообучения?
По умолчанию для любой ответственной сборки — никаких данных. Аудиозаписи и транскрипты поступают в пайплайн при каждом визите, а затем удаляются в соответствии с контрактным графиком хранения. Если переобучение требуется — оно возможно только при явном согласии пациента, данные полностью обезличиваются по стандартам HIPAA Safe Harbor или Expert Determination и обрабатываются в рамках BAA. Большинство операторов в 2026 году вообще не используют пациентское аудио для дообучения.
Когда ИИ-скрайб не подходит?
Стационарные больничные потоки, где заметки ведёт ротационная команда, потоки приёмного отделения, где форма визита слишком непредсказуема, и форензически-юридические потоки, где стандарт документирования отличается от SOAP. В этих сценариях скрайб используется как инструмент транскрипции, а слой структурированных заметок ждёт рефакторинга процесса.
Что почитать дальше
Смежная опорная статья
HIPAA и SOC 2 для телемедицинской видеоплатформы 2026
Каркас комплаенса, внутри которого работает скрайб — BAA, шифрование, аудит-лог, пути удаления.
Опорная статья по телемедицине
Разработка телемедицинской платформы 2026
Полная поверхность телемедицинского продукта, в который встраиваются скрайбы — визиты, согласие, интеграция с EHR, биллинг.
Голосовые агенты
Производственный гайд по OpenAI Realtime API для голосового агента
Паттерны голосовой обвязки в реальном времени — что выпускать, на что обращать внимание, нюанс BAA для клинических применений.
Паттерны RAG
RAG поверх записей видео, аудио и чатов
Паттерны RAG, которые обеспечивают надёжную работу LLM-стадии скрайба — чанкинг, эмбеддинги, provenance.
LLM ops
Оценка LLM-приложения в продакшене
Как держать скрайб честным в продакшене — eval-наборы, регрессионные тесты, мониторинг галлюцинаций.
Готовы выпустить ИИ-скрайб клинического уровня?
ИИ-скрайб, который действительно внедряется у клиницистов, — это семистадийный пайплайн, защищённый HIPAA, с удобным интерфейсом получения согласия пациента и интеграцией с EHR, который создаёт черновик записи за менее чем 90 секунд. Сделайте это правильно — и каждый врач будет экономить 60–120 минут в день. Сейчас это самый чистый ROI в медицинском ИИ.
Фора Софт выпустила эту поверхность внутри телемедицины в паттерне CirrusMED, поверх стека интерпретации NHS-уровня TransLinguist и как кастомную сборку для мультиспециализированного оператора. Паттерны, которые мы переиспользуем, — это те же самые паттерны. Если вы хотите, чтобы кастомный ИИ-скрайб был размечен, заскоплен и спланирован под вашу специальность, ваш состав EHR и правила резидентности данных, — через 48 часов у вас в почте будет 16-недельный план.
Пришлите бриф — получите 16-недельный план
Бесплатное 30-минутное обсуждение. Мы оценим объём работ, перечислим вендоров с BAA и пришлём план доставки с паттернами HIPAA уровня CirrusMED, которые мы уже используем.
