ИИ для стоматологии: где он помогает врачу и руководителю, а где опасен

# ИИ для стоматологии: где он помогает врачу и руководителю, а где опасен

Редакция SGI24. Материал рассматривает ИИ как контролируемый слой вокруг рабочих систем клиники. Он не описывает медицинский продукт и не заменяет решение врача. [О бюро](/company).

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

ИИ способен искать пропуски и необычные отклонения. Но граница здесь жёсткая. Подсказать ответственному специалисту, что запись неполна, и самостоятельно поставить диагноз — разные продукты с разным риском и правовым режимом.

Разобрать безопасный сценарий ИИ для клиники

Начните с управленческой задачи

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

• обращения без ответа;
• записи без подтверждения;
• частые отмены по времени, врачу или услуге;
• незакрытые задачи рецепции;
• отклонение загрузки от обычной картины.

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

Если данные приходят из сайта, телефонии и медицинской системы, сначала решается вопрос идентификаторов и качества обмена. ИИ не исправит дубли и пропущенные статусы сам по себе.

Общий порядок выбора, проверки и остановки пилота разобран в материале «Внедрение ИИ в бизнес».

Контроль полноты медицинской записи

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

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

Для такого сценария правила проверки должны быть утверждены клиникой. Нельзя позволить модели самой придумывать, какой регламент считается правильным.

Анализ потенциальных рисков лечения

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

Формулировка результата важна. Мы говорим «обнаружено отклонение, требуется проверка», а не «врач допустил нарушение» и не «лечение назначено неправильно». Контекст оценивает уполномоченный специалист.

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

Где проходит граница медицинского изделия

Росздравнадзор относит к медицинским изделиям в том числе специальное программное обеспечение, если производитель предназначил его для профилактики, диагностики, лечения, мониторинга состояния и других медицинских целей. Медицинские изделия допускаются к обращению после государственной регистрации.

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

SGI24 не маскирует этот вопрос технической оговоркой. На старте фиксируется назначение системы, круг пользователей и решение, которое остаётся за врачом.

Персональные данные нельзя отправлять куда угодно

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

Для части задач достаточно обезличенной структуры: код события, срок, статус, отсутствие поля. Если нужен текст, идентификаторы удаляются до передачи там, где это не ломает смысл.

Доступ модели не должен быть шире доступа сотрудника. Журнал хранит, какой источник использован и кому показан результат.

Что проверить по персональным данным в стоматологии

ИИ для рецепции

В работе рецепции модель может классифицировать обращения, готовить краткую сводку разговора или предлагать следующий шаг. Финальное действие остаётся в CRM или медицинской системе.

Автоматически обещать пациенту время, цену или медицинский результат опасно. Система должна опираться на реальное расписание и утверждённые правила, а нестандартный вопрос передавать человеку.

Хороший эффект часто даёт не «ИИ-администратор», а связка: корректная запись, единая очередь, контроль срока и подсказка сотруднику. Она уменьшает ручные переносы и не прячет ответственность.

Пульт главного врача и собственника

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

Пульт строится слоями. Сначала сигнал и его приоритет. Затем причина и связанные события. В конце — исходная запись в системе, доступная только пользователю с нужными правами.

ИИ может подготовить краткое объяснение, но рядом должны оставаться факты, на которых оно основано.

Как провести пилот

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

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

По итогам клиника получает решение: запускать сценарий, изменить правила, улучшить данные или остановить проект. Отрицательный результат пилота дешевле ошибочной системы в медицинском процессе.

Что не требуется менять ради пилота

Для пилота ИИ не обязательно заказывать новый сайт или замену медицинской программы. Мы подключаемся к доступному процессу, строим контролируемый прототип и возвращаем результат в привычный интерфейс.

Если выясняется, что данные разорваны между системами, интеграция становится отдельным предложением. Клиника сама решает, продолжать ли комплекс.

Какие данные нужны для первого разбора

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

Для клинически чувствительного сценария нужен владелец со стороны клиники: главный врач, медицинский директор или другой уполномоченный специалист. Он утверждает регламент, размечает контрольные примеры и принимает результат. Разработчик не подменяет эту роль.

Как измерять пользу без красивых обещаний

До пилота фиксируется, сколько случаев проверяет человек, сколько времени занимает разбор и какие ошибки обнаруживаются поздно. После запуска сравниваются те же показатели. Отдельно учитывается время на проверку сигналов модели.

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

Что получает руководитель по итогам пилота

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

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

Разобрать безопасный сценарий ИИ для клиники

Источники

• Росздравнадзор: медицинские изделия и специальное программное обеспечение
• Росздравнадзор: государственная регистрация медицинских изделий и ПО с ИИ
• NIST AI Risk Management Framework