Проблема фрагментации форматов MRN
В США насчитывается около 6 100 больниц, каждая из которых ведёт собственную систему электронных медицинских карт с уникальным форматом номера медицинской карты (MRN). Единого национального стандарта MRN не существует. Комиссия по аккредитации здравоохранения (Joint Commission) требует, чтобы MRN однозначно идентифицировал пациента в рамках системы, — но формат не регламентирует.
Следствие: в реальной практике MRN встречаются в виде 7- и 8-значных целых чисел, буквенно-цифровых строк переменной длины, форматированных строк с префиксами (HOSP-, MRN-, PT-, PAT-), кодов учреждений (SVHS-, CHOP-, MDACC-) и форматов с закодированным годом поступления.
Метод Safe Harbor по HIPAA относит номера медицинских карт к категории 8 из 18 идентификаторов, подлежащих удалению (45 CFR Section 164.514(b)(2)). Требование не зависит от формата: должны обнаруживаться и удаляться все форматы MRN, применяемые в организации. Клиника, обрабатывающая клинические заметки без распознавания своего конкретного формата MRN, не достигает обезличивания по Safe Harbor — даже если все прочие идентификаторы удалены.
Барьер программирования
Стандартный способ добавления пользовательского формата MRN в конвейер обезличивания предполагает реализацию кастомного распознавателя в Presidio. Это требует: написания Python-класса, расширяющего EntityRecognizer; определения регулярного выражения для конкретного формата; реализации метода analyze(); регистрации распознавателя в реестре Presidio; тестирования на реальных примерах; сопровождения по мере эволюции формата.
Для команд специалистов по клинической информатике без опыта Python — а это большинство сотрудников, отвечающих за соответствие в здравоохранении, — это создаёт зависимость от инженерного отдела при каждом изменении формата. Инженерные ресурсы в медицинских организациях, как правило, направлены на интеграцию EHR и поддержку клинических решений, а не на настройку инструментов соответствия.
ИИ-помощник для создания паттернов
Подход с ИИ-ассистентом заменяет программирование на управляемый интерфейс:
Команда клинической информатики открывает Конструктор пользовательских сущностей в веб-приложении. Они вводят 5 примеров MRN из своей системы (SVHS-0012345, SVHS-0987654, SVHS-1122334, SVHS-4455667, SVHS-8899001). Нажимают «Сгенерировать паттерн». ИИ анализирует структуру и возвращает: паттерн SVHS-\d{7} соответствует предоставленным примерам; уровень уверенности — высокий; предлагаемое имя сущности: HOSPITAL-MRN; предлагаемая замена: [MRN]; рекомендуется проверить на дополнительных примерах.
Команда тестирует паттерн на 5 новых примерах — он проходит валидацию. Пользовательская сущность сохраняется в пресете HIPAA. Все последующие сеансы обезличивания — в веб-приложении, надстройке Office, десктопном приложении и через API — автоматически распознают MRN формата SVHS в составе стандартного прохода обнаружения PHI.
Исключение GDPR для исследований по Статье 89 требует псевдонимизации и минимизации данных для исследовательских датасетов. Создание пользовательских сущностей гарантирует включение внутренних идентификаторов учреждения в область псевдонимизации — закрывая пробел, который оставляют универсальные инструменты для проприетарных форматов.
Источники: