Деидентификация в соответствии с HIPAA: Обнаружение специфичных форматов MRN для больниц без инженерных усилий
Деидентификация в соответствии с HIPAA требует удаления "номеров медицинских карт" как одной из 18 категорий идентификаторов. Это кажется простым, пока вы не столкнетесь с реальной операционной проблемой: номера медицинских карт не стандартизированы.
Epic генерирует MRN в одном формате. Cerner использует другой формат. Meditech использует еще один. Сетевые больницы назначают свои собственные коды учреждений. Региональные организации здравоохранения создают еще больше форматов. В результате: стандартный инструмент PII, сканирующий клинический документ на наличие "номеров медицинских карт", не имеет возможности узнать, какой формат использует ваше учреждение — и полностью пропустит их.
Это не гипотетический пробел. Команды ИТ в здравоохранении, проводящие оценки деидентификации в соответствии с HIPAA, регулярно обнаруживают, что MRN в "деидентифицированных" наборах данных все еще присутствуют, потому что инструмент анонимизации был настроен только для стандартных категорий PII.
Проблема стандартизации MRN
В здравоохранении США нет национального стандарта для формата номера медицинской карты. Каждое учреждение (или поставщик EHR) определяет свой собственный:
Общие наблюдаемые шаблоны:
- Стиль Epic: 8-12 цифр (например, 123456789)
- Стиль Cerner: Префикс кода больницы + цифры (например, MGH-987654)
- Региональные сети: Код учреждения + год + последовательность (например, HOSP-2023-456789)
- Департамент по делам ветеранов: 9 цифр с определенными шаблонами контрольных цифр
- Педиатрические системы: Префикс типа пациента + цифры (например, PED-12345678)
Ни один из этих форматов не соответствует универсальному шаблону regex для "номера медицинской карты", потому что такого универсального шаблона не существует.
Что обнаруживают стандартные инструменты PII: Стандартные реализации инструментов деидентификации HIPAA сосредоточены на идентификаторах с стандартизированными форматами: SSN (XXX-XX-XXXX), номера телефонов (XXX-XXX-XXXX), адреса электронной почты, даты. MRN, номера счетов и номера сертификатов/лицензий — категории HIPAA 8, 10 и 11 — специфичны для учреждения и требуют индивидуальной настройки.
Риск несоответствия
Региональная больничная сеть готовится поделиться деидентифицированными данными пациентов с университетским исследовательским партнером. Их EHR генерирует MRN в формате: HOSP-YYYY-XXXXXX (код больницы, 4-значный год, 6-значный номер последовательности).
Они запускают набор данных через свой стандартный инструмент деидентификации HIPAA. Инструмент удаляет:
- Имена пациентов ✓
- Даты (кроме года) ✓
- Номера телефонов ✓
- Адреса электронной почты ✓
- Географические данные меньшие, чем штат ✓
- SSN ✓
Инструмент не удаляет MRN — потому что HOSP-2023-456789 не соответствует ни одному встроенному шаблону MRN.
Исследователь получает набор данных, выполняет соединение с их внутренними записями (в которые входят MRN из направлений в ту же больницу) и может повторно идентифицировать значительный процент "деидентифицированных" пациентов. Больничная сеть нарушает HIPAA.
Этот сценарий не гипотетический — это задокументированный режим сбоя в рабочих процессах деидентификации.
Создание пользовательских сущностей: Решение
Решение заключается в том, чтобы определить формат MRN как пользовательскую сущность в инструменте анонимизации. Специалист по соблюдению норм (не инженер) может:
-
Определить формат MRN учреждения: "Идентификатор больницы, начинающийся с HOSP, затем дефис, затем 4-значный год, затем дефис, затем 6-значное число"
-
Использовать помощника по шаблонам ИИ для генерации соответствующего regex: HOSP-d{4}-d{6}
-
Проверить на образцовом документе: Загрузить 20 выписок, проверить, что шаблон захватывает все MRN
-
Сохранить как пользовательскую сущность: "MRN больницы" — теперь доступно во всех режимах обработки
-
Включить в предустановку деидентификации HIPAA: Стандартная предустановка плюс пользовательская сущность MRN охватывает все 18 категорий Safe Harbor для этого учреждения
Сроки: 3 дня времени специалиста по соблюдению норм против 3 месяцев очереди на инженерные заявки для разработки пользовательского кода.
Пример: Реализация региональной больничной сети
Организация: Региональная больничная сеть из 15 учреждений Формат MRN: HOSP-YYYY-XXXXXX (появляется в тысячах PDF выписок) Проблема соблюдения: Подготовка исследовательского набора данных для университетского партнера (договор на использование данных HIPAA подписан, требуется деидентификация) Предыдущий подход: Внешний поставщик деидентификации HIPAA (120 000 долларов в год) Обнаруженный пробел: Инструмент поставщика не обнаруживал специфичный для учреждения формат MRN
Новый рабочий процесс:
- Специалист по соблюдению норм определяет шаблон MRN (20 минут)
- ИИ помогает с проверкой regex (5 минут)
- Тестирование на 50 образцах выписок (30 минут)
- Подтверждение, что все MRN обнаружены, нет ложных срабатываний (10 минут)
- Добавление в предустановку деидентификации HIPAA наряду со стандартными сущностями
- Обработка полного исследовательского набора данных из 50 000 записей в пакетном режиме
Общее время для устранения пробела в соблюдении: 1 послеобеденное время.
Многофункциональные организации: Разные форматы MRN для каждого учреждения
Больничные сети, приобретенные в результате слияния, часто имеют несколько систем EHR — и несколько форматов MRN от устаревших установок.
Обработка нескольких форматов MRN:
Создайте отдельные пользовательские сущности для каждого формата:
- "Формат MRN A (Epic)" — 8-значный числовой
- "Формат MRN B (устаревший Cerner)" — префикс + 7-значный числовой
- "Формат MRN C (приобретенный аффилированный)" — код штата + год + последовательность
Предустановка, которая включает все три пользовательские сущности плюс стандартные идентификаторы HIPAA, охватывает все требования к деидентификации всей сети. При применении к пакету, содержащему документы из любого учреждения, все форматы MRN будут захвачены.
За пределами MRN: Другие специфичные для учреждения идентификаторы
Тот же подход к пользовательским сущностям применяется к другим категориям HIPAA Safe Harbor, которые организации реализуют с нестандартными форматами:
Номера бенефициаров плана здоровья (Категория 9): Идентификаторы членов страхования специфичны для страховщика. Aetna, Blue Cross, United Healthcare используют разные форматы. Система больницы, обрабатывающая счета, нуждается в пользовательских шаблонах для каждого плательщика, с которым она работает.
Номера счетов (Категория 10): Номера счетов больницы для выставления счетов (не клинические MRN) специфичны для учреждения.
Номера сертификатов/лицензий (Категория 11): Номера DEA врачей имеют стандартный формат. Номера медицинских лицензий штатов не имеют — каждая лицензирующая комиссия штата использует другой формат.
Идентификаторы устройств (Категория 14): Серийные номера медицинских устройств специфичны для производителя.
Для каждой из этих категорий создание пользовательских сущностей позволяет командам по соблюдению норм закрыть пробелы в обнаружении без инженерных ресурсов.
Проверка: Подтверждение соблюдения Safe Harbor
Метод Safe Harbor HIPAA требует, чтобы покрываемая организация "не имела фактических знаний о том, что информация может быть использована отдельно или в сочетании с другой информацией для идентификации лица, являющегося субъектом информации."
Для специалиста по соблюдению норм, применяющего обнаружение пользовательских сущностей, проверка — это демонстрация того, что все 18 категорий охвачены:
- Обработать образец из 50-100 документов из исследовательского набора данных
- Вручную просмотреть обработанный вывод — выглядит ли что-то как потенциальный идентификатор?
- Запустить вывод через второй проход обнаружения (для любых шаблонов, которые могли быть пропущены)
- Документировать процесс проверки
Конфигурация пользовательской сущности, результаты выборки проверки и метаданные обработки вместе составляют документальную запись для деидентификации Safe Harbor.
Заключение
Деидентификация в соответствии с HIPAA Safe Harbor не достигается стандартными инструментами PII, настроенными на общие шаблоны. Номера медицинских карт — одна из 18 обязательных категорий — специфичны для учреждения и требуют индивидуального обнаружения для соблюдения норм.
Создание пользовательских сущностей закрывает этот пробел за часы, а не месяцы. Специалисты по соблюдению норм могут определять специфичные для учреждения шаблоны, проверять их на образцовых документах и производить действительно соответствующий требованиям Safe Harbor вывод без инженерных ресурсов.
Пробел в соблюдении между "мы запустили инструмент деидентификации HIPAA" и "мы действительно удалили все 18 идентификаторов Safe Harbor" часто составляет всего одну неконфигурированную пользовательскую сущность.
Источники: