Проблемът с поверителността при ИИ клиничните бележки
Актуализирано за 2026 г.
Болниците и клиниките използват ИИ за писане на клинични бележки. ИИ транскрибира глас и изготвя текст. Но това създава пропуск в HIPAA, който ръчният преглед не може да запълни.
ИИ генерираните бележки излагат пациентски записи по три начина:
- Кръстосано замърсяване: ИИ може да пренесе информация от един пациент в записа на друг пациент. Медицинските изследвания на ИИ са показали този риск.
- Контекстуално изтичане: Пациентска информация попада в грешното поле - в бележка за фактуриране, изследователско поле или формуляр за препращане. ИИ попълва полета по контекст, не по предназначение на полето.
- Използване на данни от доставчика: Много ИИ доставчици изпращат бележките обратно за преглед на модела, освен ако не се откажете от това. Това изпраща пациентска информация към сървъри на трети страни. Тези сървъри може да нямат подписано споразумение за бизнес партньор (BAA).
HHS публикува предложено правило през 2025 г. То гласи, че субектите, използващи ИИ инструменти, трябва да включат тези инструменти в анализа си на риска. Това създава формално правило за ИИ подпомаганата клинична работа.
Правилото на HHS от 2025 г. за анализ на риска от ИИ
HHS предложи нови правила за покритите субекти, използващи ИИ. Всяка ИИ система, която докосва пациентски записи, трябва да се появи в анализа на риска на субекта.
Правилото има три части:
Технически гаранции: Прегледайте всеки ИИ инструмент. Питайте:
- Изпраща ли пациентски записи извън вашите системи?
- Съхранява ли пациентски записи на своите сървъри след употреба?
- Записва ли пациентска информация в грешния запис?
Обучение на персонала: Обучението трябва да обхваща специфичните рискове от ИИ. Това включва случаи на объркване на записи.
Физически контроли: Работните станции, работещи с ИИ инструменти, трябва да бъдат част от физическите контроли за достъп.
Клиничните ИИ инструменти включват услуги за конвертиране на глас в текст, инструменти за изготвяне на ИИ бележки и инструменти за кодиране.
Защо засичането преди запис работи
Най-добрият технически контрол е засичането на PHI преди бележката да се запише в ЕЗД.
Без засичане преди запис:
- ИИ пише чернова
- Персоналът я преглежда ръчно, под времеви натиск
- Бележката се записва в ЕЗД
- PHI грешките вече са в постоянния запис
- Коригирането им изисква одитни записи и преглед за нарушение
Със засичане преди запис:
- ИИ пише чернова
- PHI сканирането се изпълнява преди записването на бележката
- Маркираните елементи отиват при персонала за преглед
- Персоналът коригира грешките преди запис
- Записът в ЕЗД е чист от самото начало
Засичането преди запис отговаря на правилото за сигурност на HIPAA 164.312(b). Това правило изисква системи, записващи и проверяващи дейността. Сканирането преди запис създава одитен запис за всяка прегледана бележка.
18-те PHI категории в ИИ бележките
CHIPAA Safe Harbor изисква премахване на 18 категории PHI (45 CFR 164.514(b)). ИИ бележките могат да съдържат всички 18 по начини, които може да не очаквате:
- Имена - пациент споменава член на семейството в историята на симптомите
- Местоположение - домашен адрес в социалната история
- Дати - дати на раждане, дати на хоспитализация, дати на процедури
- Телефонни и факс номера - данни за контакт в бележки за препращане
- Имейл адреси - данни за контакт, предоставени от пациента
- ЕГН - застрахователен контекст
- Номера на медицинска документация - кръстосани препратки в ИИ резюмета
- Номера на здравни планове - застрахователен контекст
- Номера на сметки - контекст на фактуриране
- Номера на удостоверения/лицензи - информация за лиценза на доставчика в препращания
- Идентификатори на превозни средства - контекст на произшествие в травматологични бележки
- Идентификатори на устройства - бележки за импланти
- URL адреси - предадени от пациента връзки към здравни записи
- IP адреси - журнали за отдалечени сесии
- Биометрични идентификатори - данни от пръстови отпечатъци или гласов отпечатък
- Снимки - свързани медии в ИИ системи
- Всеки друг уникален идентификатор - персонализирани идентификатори на заведения
ИИ моделите могат да създадат всяко от тях от контекст. Засичането трябва да обхваща всички 18 - не само ЕГН и дати.
Как да добавите засичане преди запис
Проверката за PHI преди запис следва пет стъпки:
- ИИ пише чернова на бележката
- Текстът на бележката отива в API за засичане преди персоналът да го види
- Маркираните елементи се показват в изгледа на черновата
- Персоналът преглежда маркираните елементи по време на нормалния преглед на бележките
- Персоналът записва бележката - без маркираните елементи или с регистрирана причина
Какво изисква системата:
- Скорост: под 200 ms, за да не забавя работния процес
- Покритие: всички 18 категории HIPAA плюс местни шаблони като вашия формат на номер на медицинска документация
- Оценяване: елементи над 85% се маркират автоматично; 50-85% изискват преглед от персонала; под 50% се показват само за справка
- Одитен журнал: записва всеки маркиран елемент, оценката му и решението на прегледащия
Одитният журнал ви дава директно доказателство за анализа на риска на HHS. Той показва, че имате контроли за PHI, генериран от ИИ.
Казус: Засичане преди запис в медицински център
Един академичен медицински център използвал ИИ амбиентна система за лекарски бележки. 90-дневен одит открил два случая на объркване. Една бележка имала датата на раждане на друг пациент. Втора имала името и ЕГН на член на семейството от социалната история.
След добавяне на засичане на PHI преди запис:
- Всички ИИ чернови се сканирали преди преглед от лекаря
- Средно време на сканиране: 47 ms - не се усеща в работния процес
- За 90 дни: 1 247 елемента маркирани в 8 400 бележки
- Персоналът прегледал и разрешил 94% от маркираните елементи
- Нула инцидента с объркване на записи след внедряването
Системата произвежда месечен отчет. Той показва нива на засичане, нива на преглед и типове субекти. Този отчет служи като доказателство за контроли при одит по правилото за сигурност на HIPAA 164.312(b).
Екипите, изграждащи този работен процес, могат да използват API за засичане на PHI на anonym.legal. Той обхваща всички 18 категории HIPAA при латентност под 200 ms. Вижте наръчника за интеграция на засичане на PHI за стъпките на настройка. За пълен контекст, посетете страницата употреби в здравеопазването.