ШІ для клініки та кабінету: реєстрація та обслуговування, а не діагностика

Клініка з п’ятьма лікарями, тридцять дзвінків на день до реєстратури, три чверті з них — це підтвердження візиту або запитання про підготовку до аналізу крові натщесерце. Реєстраторка приймає кожен окремо. Це не проблема діагностики. Це проблема адміністративного процесу, який можна вирішити за допомогою ШІ без втручання в клінічну сферу.

Але цей самий аргумент часто розтягують надто далеко. «ШІ оцінить, чи варто йти до лікаря» звучить як розвантаження реєстратури, а насправді є прихованою спробою клінічного тріажу за допомогою інструменту, який не має ні компетенції, ні права на це. Межа між цими двома випадками є чіткою. Нижче ми її окреслимо.

Адміністративні завдання в медичному закладі є повторюваними, структурованими та чітко визначеними. Саме ці характеристики, за яких ШІ працює найкраще.

Реєстрація та запис на візити. Агент ШІ з доступом до календаря лікарів може приймати запити на візит через чат, SMS або форму, пропонувати вільні терміни та підтверджувати бронювання. Також може обробляти скасування та перенесення. Він не приймає клінічних рішень, лише керує слотами в графіку. Порівнянний технічний шаблон описано в агенті ШІ для запису на зустрічі.

Нагадування та follow-up. Автоматичні SMS або e-mail за 24 години до візиту зменшують кількість неявок (дослідження оцінюють 20-40% скорочення no-show у закладах з нагадуваннями). Тут немає жодної клінічної обробки, лише контактні дані та термін.

FAQ щодо підготовки до обстежень. Відповідь на запитання «чи потрібно бути натщесерце перед аналізом ТТГ» — це медичний факт із бази знань, а не клінічна оцінка пацієнта. RAG на перевірених матеріалах клініки (протоколи підготовки, стандарти лабораторії) дає відповіді, узгоджені з процедурами закладу, без ризику імпровізації моделі.

Попередній збір причин візиту. Агент може запитати, з чим пов’язаний візит, і передати цю інформацію лікарю перед входом пацієнта. Це адміністративне структурування даних, а не діагностика. Різниця проста: агент запитує «З чим пов’язаний візит?», а не «Що Вас турбує і наскільки це може бути серйозно?».

Цей список короткий, але абсолютний.

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

Клінічний тріаж (оцінка терміновості на основі симптомів) належить медичному персоналу. Агент може запитати про причину візиту та передати її лікарю або реєстраторці. Він не може оцінювати, чи повинен пацієнт їхати до швидкої допомоги, чи почекати на візит за тиждень.

Інтерпретація результатів обстежень. Результат загального аналізу крові, ТТГ, СРБ — це клінічні дані. Відповідь «результат виглядає нормально» або «результат поза нормою, це означає Х» — це діагноз у розумінні права, а не адміністративна інформація.

AI Act (Додаток III, пункт 5) охоплює системи ШІ, що застосовуються для підтримки клінічних рішень, як системи високого ризику. Впровадження без необхідної документації, без людського нагляду, без оцінки наслідків (DPIA) є порушенням європейського права. Більший правовий контекст: AI Act у медицині та системи високого ризику.

Дані пацієнта (ім’я, PESEL, термін візиту, причина візиту) — це персональні дані. Причина візиту, результати обстежень, діагнози — це конфіденційні дані у розумінні RODO ст. 9 — особлива категорія, що вимагає окремої правової основи та посилених заходів безпеки.

Три архітектурні рішення мають тут найбільший вплив.

Self-hosting або data residency EU. Медичні дані пацієнтів не повинні залишати інфраструктуру закладу або ЄС без чіткої правової основи та договору доручення. Локальний LLM (модель, що працює на сервері клініки або в дата-центрі ЄС) усуває цю проблему структурно. Альтернативою є постачальник хмарних послуг з data residency PL/ЄС та підписаною угодою ст. 28 RODO. Шаблон розглянуто в self-hosted LLM та RODO.

PII masking перед обробкою. Агентам ШІ не потрібно бачити повні дані пацієнта, щоб виконати своє завдання. Номер PESEL, адреса, номер телефону можуть бути замасковані перед відправкою до моделі, залишаючи лише ID сесії. Логи розмов, що зберігаються без PII, зменшують ризик у разі порушення безпеки. Техніки описано в анонімізації PII перед ШІ.

Ретенція та право на видалення. Пацієнт має право вимагати видалення даних (RODO ст. 17). Архітектура повинна це технічно підтримувати: логи розмов з агентом мають бути пов’язані з ID пацієнта та видалятися на вимогу. Зберігання логів у неузгодженій структурі, з якої неможливо зрозуміти, що стосується кого, — це проблема відповідності, а не лише організаційна.

DPIA є обов’язковою, коли обробляються медичні дані у великому обсязі або коли система приймає автоматичні рішення, що впливають на доступ пацієнта до послуг (наприклад, автоматичне відхилення заявки на візит на основі історії). Для стандартної системи реєстрації без елементів автоматичних рішень DPIA може не бути обов’язковою, але варто провести попередню оцінку.

Впровадження асистента ШІ в клініці займає 4-8 тижнів для адміністративного обсягу. Етапи:

Тиждень 1-2: аудит процесів. Каталог запитань, які сьогодні надходять до реєстратури. Поділ на адміністративні (можна автоматизувати) та клінічні (завжди до лікаря). Без цього кроку система відповідатиме на клінічні запитання, бо пацієнти їх ставлять.

Тиждень 2-4: побудова бази знань RAG. Вихідні документи: протоколи підготовки до обстежень, прайс-лист, графік лікарів, процедури реєстрації, FAQ з сайту закладу. Це контент, на якому базується агент. Якість бази знань безпосередньо визначає якість відповідей. Детальний шаблон: підготовка корпоративних даних під ШІ.

Тиждень 3-5: guardrails та тестування. Кожна система в медичному закладі повинна мати жорсткі обмеження: список тем, на які агент не відповідає (симптоми, діагностика, дозування ліків), автоматична ескалація до реєстраторки, коли тема виходить за межі, дисклеймер, що розмови не замінюють медичної консультації.

Тиждень 5-8: пілот shadow mode. Агент працює паралельно з реєстраторкою, його відповіді логуються та перевіряються. Лише після 2-3 тижнів без суттєвих відхилень настає самостійне обслуговування окремих категорій запитів. Шаблон пілотування: план впровадження ШІ крок за кроком.

Не автоматично. Система, що обслуговує виключно адміністрацію (запис на візити, нагадування, FAQ щодо підготовки до обстежень), не підпадає під Додаток III AI Act, який стосується систем, що підтримують клінічні рішення. Однак межа є процедурною, а не технічною: якщо агент відповідає на запитання про симптоми або рекомендує, чи варто йти до лікаря, він потрапляє в клінічну сферу, і класифікація змінюється. Обсяг системи має бути задокументований та забезпечений guardrails.

Для адміністративних даних (контакт, термін візиту) основою найчастіше є ст. 6 п. 1 літ. b (виконання договору) або літ. c (правовий обов’язок). Для медичних даних застосовується ст. 9 п. 2 — на практиці медичні заклади найчастіше використовують літ. h (профілактика здоров’я, медична діагностика, лікування персоналом, зобов’язаним зберігати таємницю) або літ. a (чітка згода). Вибір правової основи впливає на можливість обробки, ретенцію та права пацієнта. Консультація з інспектором захисту даних рекомендована перед впровадженням.

Стандартна система нагадувань про візити (ім’я, термін, контактний номер) у масштабі типової клініки, як правило, не вимагає DPIA. DPIA є обов’язковою, коли обробка може призвести до високого ризику для прав фізичних осіб, зокрема при великому масштабі, систематичному моніторингу або автоматичних рішеннях з суттєвими наслідками. Якщо нагадування містять інформацію про вид візиту або спеціалізацію (що може розкривати стан здоров’я), поріг ризику зростає.

Може збирати структуровану інформацію: причина візиту (в одному реченні), тривалість симптомів, чи лікувався пацієнт з цього приводу раніше. Не може оцінювати, класифікувати терміновість або пропонувати діагноз на основі цих даних. Зібрані дані передаються лікарю як контекст, а не як оцінка. Межа тут технічно тонка, тому вимагає точних guardrails та тестування перед впровадженням.

Логи розмов з агентом виконують дві функції: дебагінг (короткий термін, зазвичай 30-90 днів) та підзвітність системи ШІ (довший термін, пов’язаний з ретенцією медичної документації). Логи, що містять PII пацієнта, повинні видалятися на вимогу (RODO ст. 17) і не повинні зберігатися довше, ніж це необхідно для мети. Архітектура має забезпечувати пошук та видалення логів конкретного пацієнта без видалення всієї історії системи.