Что делает
Patient intake автоматизирует весь pre-visit путь пациента: от первого контакта до готового к приёму электронного досье. AI-агент работает с анкетами, страховыми данными, фото документов и историей болезни — собирает, проверяет и структурирует без участия регистратора. Для клиники это значит, что в момент прихода пациента врач открывает заполненную карту, а регистратура не тонет в ручном вводе.
Что именно делает автоматизация
- Отправляет приглашение. Сценарий стартует за 48 часов до приёма, шлёт защищённую ссылку через SMS или email в канале Communications с HIPAA-покрытием.
- Ведёт адаптивный опросник. Пациент отвечает на демографию, жалобы, аллергии, медикаменты. Агент подстраивает вопросы под тип визита.
- Извлекает данные из документов. Фото страхового полиса, ID, рефералов и предыдущих выписок проходят через OCR и vision-модель — нужные поля заполняются без ручного ввода.
- Проверяет страховое покрытие. Отправляет запрос в клиринговый сервис, получает статус полиса, co-pay и eligibility.
- Классифицирует случай. Агент определяет тип визита (первичный, follow-up, срочный), делает триаж по жалобам и направляет к подходящему специалисту.
- Синхронизирует Calendar. Подтверждает слот, блокирует подготовку, отправляет напоминания за 24 и 2 часа.
- Передаёт досье в EHR. Готовая запись попадает в карту пациента — врач видит заполненный документ до начала приёма.
- Логирует HIPAA-события. Каждое действие с PHI фиксируется в immutable-логе для аудита.
Чего автоматизация не делает
- Не ставит диагнозы и не принимает медицинские решения: AI собирает данные, врач интерпретирует.
- Не работает без BAA (Business Associate Agreement) с поставщиками AI, хостинга и communications. Если BAA не подписан — запускать нельзя.
- Не покрывает telehealth-визиты из коробки: video-протоколы и remote monitoring требуют отдельной конфигурации.
Кому подходит
Clinics с outpatient-форматом, где регистратура перегружена ручным вводом, а ошибки в intake-данных приводят к отказам страховых и переделкам. Минимальный порог — 500–800 визитов в месяц, чтобы окупить BAA-слой и инфраструктуру. Меньший объём эффективнее закрыть простыми веб-формами без AI.
Для дерматологической практики на 8 врачей эффект составил $185K в год при $12 900 инвестиций — 1334% ROI. Ключевое — не само сокращение времени на 92%, а освободившиеся часы регистратора, которые ушли на сложные кейсы: нестандартные страховки, апелляции, follow-up.
Как работает
Технически Patient intake — это многошаговая оркестрация поверх существующего стека клиники. AI-агент не заменяет EHR или PM-систему, а дополняет их как HIPAA-совместимая обвязка на vertical-SaaS-ядре.
Архитектура потока
- Триггер. Событие «пациент записан» в PM-системе отправляет webhook — стартует сценарий агента.
- Conversational слой. Пациент взаимодействует через защищённый веб-портал или chat-канал Communications с BAA-покрытием. Без логина — ссылка одноразовая, привязана к appointment ID.
- Document AI. Загруженные фото проходят через OCR и vision-модель. Из неструктурированных документов извлекаются поля: номер полиса, группа, имя plan-holder, даты.
- Validation. Данные проверяются против формата (структура полиса, NPI-справочник, корректность дат). Сравнение с базой клиники на дубли.
- Classification agent. AI-агент классифицирует визит по жалобам и маршрутизирует в нужную специализацию. При низком confidence — fallback на регистратора.
- Integration bus. Готовая структура пушится в EHR через FHIR или HL7 API. Если прямой API недоступен — RPA-коннектор переносит данные как бот-оператор.
- Audit log. Все действия с PHI пишутся в immutable-лог с user ID, timestamp и scope доступа.
Компоненты решения
Слой | Назначение | Пример роли |
|---|---|---|
Vertical-SaaS ядро | HIPAA-совместимая платформа intake | Готовая конфигурация форм и workflow |
AI extraction | OCR + vision-модель для документов | Распознавание полиса и истории болезни |
Orchestration | Многошаговое управление сценарием | Триггеры, условия, fallback на оператора |
Calendar connector | Синхронизация слотов | Блокировка подготовки, напоминания |
Communications | SMS, email, чат с пациентом | Доставка ссылок и сообщений |
Compliance layer | BAA, шифрование, аудит | Логирование PHI-действий |
Шаги внедрения
- Недели 1–2: дискавери и BAA. Карта процесса as-is, инвентаризация форм и интеграций. Параллельно — подписание BAA с вендорами.
- Неделя 2–3: инфраструктура. Закрытый VPC, шифрование at-rest и in-transit, role-based access, тестовое подключение к EHR.
- Недели 3–4: сборка агента. Конфигурация опросника под специализацию, настройка extraction-промптов, подключение к PM-системе, сценарии на синтетических данных.
- Неделя 4: пилот. 1–2 врача, 50–100 реальных пациентов, ручная проверка качества, калибровка порогов confidence для классификации и extraction.
- После пилота: масштабирование на всю клинику, квартальные аудиты HIPAA, ретро с регистратурой для iteration.
Границы автоматизации
Порог confidence — ключевой параметр. При значении ниже настройки (типично 0,85) случай уходит в очередь регистратору. Это компромисс между автоматизацией и точностью: лучше задержать 5–7% сложных случаев, чем пропустить 0,5% ошибок в EHR. В дерматологической практике порог калибровали до устойчивого error rate 0,3% — снижение с исходных 3,8%.
Что нужно
Для запуска Patient intake нужен набор организационных, юридических и технических предпосылок. Основная работа — не внутри AI-агента, а в compliance-слое и интеграциях с EHR.
Данные и доступы:
- BAA (Business Associate Agreement) с AI-провайдером, хостингом и communications-вендором — обязательно по HIPAA.
- API-доступ к EHR через FHIR или HL7 либо согласие на RPA-интеграцию для legacy-систем.
- Текущие intake-формы в любом виде (PDF, бумага, веб) — для сохранения привычного пациенту сценария.
- Список источников документов: страховой полис, ID, рефералы, предыдущие выписки.
- Настроенный клиринговый сервис для проверки страховки или готовность подключить одного из стандартных вендоров.
- Baseline-метрики: текущее время на intake, error rate, wait time — нужны для сравнения через 30 и 90 дней.
Команда и процессы:
- Product owner со стороны клиники — operations manager или administrator (4–8 часов в неделю на пилоте, 1–2 часа после).
- Privacy Officer — подписывает BAA, валидирует security controls, отвечает за HIPAA risk assessment.
- 1–2 врача-ранних пользователей и регистратор для UAT, калибровки триажа и обратной связи по пациентскому опыту.
- Еженедельный ретро-слот на первые 8 недель — критично для iteration и закрытия edge-cases.
Таймлайн:
- 4–6 недель от подписания BAA до продуктивного пилота на 1–2 врачах.
- Ещё 2–4 недели на масштабирование на всю клинику с обучением регистраторов и адаптацией под каждую специализацию.
Боли
- Ошибки в ручных операциях
- Ручной ввод данных
- Медленный отклик клиентам
FAQ
Сколько занимает внедрение?
Базовый пилот — 4–6 недель: 1–2 недели на дискавери и подписание BAA, неделя на инфраструктуру и шифрование, неделя на сборку агента, неделя на UAT с живыми пациентами. Масштабирование на всю клинику — ещё 2–4 недели с учётом обучения регистраторов и калибровки триажа под каждую специализацию. Без BAA сроки сдвигаются — юридическая часть критична и часто занимает больше, чем техническая.
Что если у нас нет API в EHR?
Решение работает и без прямой интеграции. Для legacy-систем без FHIR или HL7 подключается RPA-коннектор: агент формирует готовое досье в структурированном виде, а бот-оператор переносит данные в EHR как регистратор. Это добавляет 1–2 недели на разработку и требует отдельного тестирования стабильности, но не блокирует запуск. При обновлении EHR до API-совместимой версии RPA-слой отключается без переделок агента.
Какие риски и что может сломаться?
Три типичных риска: 1) Низкое качество фото документов — решается подсказками в интерфейсе и retry-логикой с vision-моделью. 2) Страховые API падают или отвечают медленно — нужен fallback на ручную проверку с SLA для регистратора. 3) Пациенты не заполняют анкету до визита — закрывается каскадом напоминаний и ручным звонком за 4 часа. Каждый риск обрабатывается отдельным сценарием в агенте, а не игнорируется.
Подходит ли нам, если мы не дерматология?
Да, если у вас outpatient-формат: терапия, педиатрия, стоматология, женское здоровье, ортопедия, офтальмология. Логика intake повторяется — меняются формы, триаж и страховые особенности. Для узких специализаций (онкология, психиатрия) конфигурация занимает больше времени из-за сложных анамнезов и федеральных ограничений на PHI. Inpatient и emergency-форматы требуют другой архитектуры — этот сценарий не про них.
Как обеспечивается HIPAA-compliance?
Четыре слоя: 1) BAA со всеми вендорами в цепочке — AI, хостинг, communications. 2) Шифрование PHI в transit и at-rest плюс закрытый VPC. 3) Role-based access с логированием каждого действия в immutable-лог. 4) Annual risk assessment и penetration test. AI-агент работает с моделями на zero-retention политике — данные пациентов не используются для обучения и не сохраняются у провайдера после обработки.
Кто проверяет данные, если AI ошибся?
Каждое извлечённое поле имеет confidence score. Если он ниже порога (настраивается, типично 0,85), запись уходит в очередь регистратору на ручную проверку. Это сознательный компромисс: лучше задержать 5–7% сложных случаев, чем пропустить 0,5% ошибок в EHR. Порог калибруется на пилоте под конкретную специализацию — в дерматологии он вывел error rate на 0,3% против исходных 3,8%.
Как измерять эффект автоматизации?
Четыре метрики, фиксируемые на baseline до старта: время на ввод данных (целевое снижение 80%+), error rate в intake-полях (цель ниже 0,5%), wait time в зоне ожидания, patient satisfaction score по процессу заполнения. Первое сравнение — через 30 дней после пилота, второе — через 90. В референс-кейсе дерматологии результаты: data entry с 2–3 часов до 15 минут, error rate с 3,8% до 0,3%, wait time с 22 до 4 минут.
Хотите такую автоматизацию в своём бизнесе?
Запишем на бесплатный аудит — покажем, как это будет работать именно у вас.