Проблема фрагментации формата MRN
В Соединенных Штатах насчитывается около 6,100 больниц, каждая из которых использует свою собственную систему электронных медицинских записей с собственным форматом номера медицинской карты. Нет национального стандарта MRN. Совместная комиссия, аккредитующая организации здравоохранения, указывает, что MRN должны уникально идентифицировать пациентов в системе — но не указывает формат.
Следствие: форматы MRN в дикой природе включают 7-значные целые числа, 8-значные целые числа, алфавитно-цифровые строки различной длины, форматированные строки с префиксами (HOSP-, MRN-, PT-, PAT-), институциональные коды, добавленные в начало (SVHS-, CHOP-, MDACC-), и форматы с кодированием даты, где год зачисления встроен в номер.
Метод деидентификации HIPAA Safe Harbor перечисляет номера медицинских карт как категорию 8 из 18 идентификаторов, которые необходимо удалить (45 CFR Section 164.514(b)(2)). Требование не квалифицировано по формату — все форматы MRN, используемые организацией, должны быть обнаружены и удалены. Организация, которая обрабатывает клинические заметки, не обнаруживая их конкретный формат MRN, не достигает деидентификации HIPAA Safe Harbor, независимо от того, какие другие идентификаторы удаляются.
Препятствие кодирования
Стандартный подход к добавлению пользовательского формата MRN в пайплайн деидентификации требует реализации формата в пользовательской рамке распознавателя Presidio. Это включает в себя:
Написание класса Python, который расширяет EntityRecognizer, определение шаблона regex для конкретного формата MRN, реализация метода analyze(), который применяет шаблон, добавление распознавателя в реестр Presidio, тестирование реализации на репрезентативных образцах и поддержание реализации по мере изменения формата.
Для команд клинической информатики без экспертизы в Python — что описывает большинство сотрудников по соблюдению норм и конфиденциальности в здравоохранении — это создает зависимость от инженерной команды для каждого изменения формата. Инженерные ресурсы в организациях здравоохранения обычно выделяются на интеграцию EHR и поддержку клинических решений, а не на конфигурацию инструментов соблюдения.
Помощник по шаблонам ИИ
Подход к созданию шаблонов с помощью ИИ заменяет рабочий процесс кодирования на управляемый интерфейс:
Команда клинической информатики открывает Custom Entity Creator в веб-приложении. Они предоставляют 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 требует псевдонимизации и минимизации данных для исследовательских наборов данных. Создание пользовательских сущностей гарантирует, что специфичные для учреждения идентификаторы включены в область псевдонимизации — закрывая пробел в охвате, который оставляют открытыми общие инструменты.
Источники: