ИИ без права на диагноз: как автоматизировать административный контур клиники

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

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

Схема: граница задается полномочиями системы, а не формулировкой запроса 

Отделить действие от медицинского смысла

Практический тест звучит так: может ли ответ или действие системы изменить назначенное обследование, лечение либо оценку срочности? Если да — в описываемой схеме это уже не административная автоматизация. Если ответ неочевиден, система выбирает передачу обращения человеку.

К административному контуру можно отнести:

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

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

Три зоны полномочий

Удобно заранее распределить операции по трем зонам. Это превращает общую установку «не принимать медицинские решения» в проверяемые правила.

Рабочее правило: неясность — не ошибка классификации, которую нужно скрыть, а штатная причина для передачи обращения человеку.

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

Одна кнопка подтверждения врачом не превращает такую функцию в административную. 

Почему одного запрета в промпте недостаточно

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

Минимальный набор ограничений:

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

Как проходит одно обращение

Понятная схема состоит из пяти шагов.

1. Система фиксирует канал, отправителя и доступный ему контекст.
2. Берет только данные, необходимые для выбранного административного сценария.
3. До обращения к модели проверяет правила доступа и признаки обязательной передачи решения человеку.
4. В зеленой зоне выполняет разрешенную операцию; в желтой — создает карточку согласования; в красной — прекращает сценарий.
5. Записывает не только «успешно», но и предложенное действие, сработавшее правило, решение сотрудника и фактический результат.

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

Данные: брать только необходимое

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

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

Из этого не следует универсальный рецепт для любой клиники. Конкретное правовое основание, роли организации и поставщика, локализацию, договоры, сроки хранения и порядок доступа необходимо проверить для выбранной архитектуры вместе с юристом, ответственным за персональные данные и специалистом по информационной безопасности. Реальные данные пациентов нельзя переносить в неутвержденные публичные ИИ-сервисы «для проверки идеи». Для разработки используют синтетические либо корректно обезличенные наборы. 

Журнал должен восстанавливать цепочку события

Записи «запрос выполнен» недостаточно. При разборе инцидента нужно понять:

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

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

Пилот: сначала наблюдать, потом действовать

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

Перед ограниченным запуском должны быть готовы:

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

Что измерять

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

Операционные показатели:

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

Показатели контроля:

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

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

Кто задает границы

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

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

Короткий чек-лист перед пилотом

До подключения к рабочим системам руководителю проекта стоит получить семь однозначных ответов:

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

Главный принцип

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

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