В этой небольшой статье мне бы хотелось затронуть некоторые, возможно, для кого-то не совсем очевидные аспекты тестирования интерфейсов медицинских систем.
И хотя чаще всего взаимодействие таких систем основано на одном из протоколов Health Level 7 (HL7), это не является обязательным условием; можно использовать и другие методы связи (например, мы можем назвать ASTM Continuity of Care Records (CCR) до того, как он был адаптирован HL7 под названием CCD).
И так, после того, как интерфейс между медицинскими системами реализован, следующим шагом будет проведение ряда различных тестов, направленных на проверку выполнения бизнес-требований (приемочное тестирование или приемочные испытания, кстати, статьи в Wiki на русском языке нет) об этом виде тестов) и технологических требований к реализации (интеграционное тестирование и модульное тестирование).
Оба типа тестирования невозможны без тестовых данных.
Эта статья об одном из аспектов создания тестовых данных для тестирования медицинских систем.
Чтобы было легче понять задачу, посмотрим, как это происходит в общем случае.
Команда тестирования получает дамп базы данных из производственной системы.
Эти данные состоят из трёх достаточно условных групп: данные для самого тестирования, справочные данные для тестов и справочные данные для приложения.
Для проверки корректности работы программы (проверки выполнения технологических требований) тестировщик может создать собственные фейковые данные, охватывающие все три типа.
Другие виды тестирования, такие как приемочное тестирование, интеграционное тестирование, тестирование нефункциональных требований (опять же, статьи в вики на русском языке нет), требуют более сложных тестовых данных, а также достаточного количества тестовых данных для проверки работоспособности системы.
В случае с медицинскими системами (когда это делается правильно, а не на коленях) возникает задача управления данными испытаний при разработке и тестировании таких систем с учетом соблюдения действующих законов и правил, направленных на защиту демографических и медицинских данных пациентов.
информацию от случайного или преднамеренного раскрытия.
Именно для этого и используется деидентификация данных, о чем я и хотел рассказать в этой статье.
Деидентификация информации о пациенте чрезвычайно важна не только при разработке и тестировании медицинских систем, как может показаться на первый взгляд, но и при использовании в аналитических системах, о чем я писал в последний раз — (Информационные сети общественного здравоохранения и поддержка клинических исследований).
Вот лишь несколько причин, по которым необходима деидентификация данных: Ноутбуки разработчиков, жесткие диски или флэш-накопители могут быть потеряны или украдены; возможны хакерские атаки на малозащищенные компьютеры разработчиков, в том числе изнутри компании и многое другое.
О реальных примерах можно прочитать на сайте - databreachtoday.com - и хотя первая страница этого сайта, вероятно, будет отличаться от того, что я вижу на момент публикации этой статьи, более чем вероятно, что по крайней мере одна статья будет посвящена медицинским данным, HIPAA или аналогичному закону.
Во всех вышеперечисленных и других случаях регуляторы требуют немедленного уведомления в случае утечки или потери персональных данных.
Более того, в погоне за горячими фактами СМИ попытаются раздуть потерю даже небольшого количества персональных данных в глобальную проблему (опять же, см.
сайт выше).
У меня была возможность следить через газетные публикации за группой медицинских аналитиков, которые в целом были уволены и преданы суду, а через год восстановлены в должности с извинениями именно из-за доступа к медицинским данным.
Прежде чем продолжить рассказ, небольшое домашнее задание.
Одна компания утверждает, что приведенные ниже данные являются тестовыми: Ронда Джеймс; Дата рождения: 08 сентября 1988 г.
; Адрес: 71 Ansubet Dr, Чарльстон, Западная Вирджиния.
Дениз Льюис; Дата рождения: 3 марта 1976 г.
; Адрес: 23 Adams Chapel Rd, Манкато, Миннесота Розмари Харди; Дата рождения: 14 ноября 1985 г.
; Адрес: 310 Camp Creek Rd, Уэстон, Массачусетс Это похоже на тестовые данные? Да, кажется.
Однако компания также утверждает, что это не просто данные испытаний, но и обезличенные данные.
Я взял WhitePages и провел поиск по одному из имен и штата проживания.
Оказалось, что с такими данными там было несколько человек.
Домашний адрес не совпадает, но всегда можно сказать, что человек переехал и т. д. Так что, пока на это не обратит внимание какая-нибудь Ронда или Дениз или СМИ, компания может спать спокойно, проблемы могут начаться позже.
Предположим, вы решили все сделать правильно и подготовили достаточное количество обезличенных тестовых данных.
(Опять же речь идет о медицинских системах и их взаимодействии; я не пытаюсь углубляться в какие-то смежные области.
) Прежде чем руководитель проекта или архитектор или самый главный тестировщик примет такое решение и бросится писать парсер для базы данных дамп, стоит учесть, что другие уже сталкивались с этим, долго думали и придумали разные подходы к созданию этих самых обезличенных данных, такие как: сокращение данных, модификация данных, подавление данных и т.д. Для знакомства предлагаю прочитать Инструменты для деидентификации личной медицинской информации написанный Россом Фрейзером и Доном Уиллисоном.
Даже если вы ничего не понимаете (что более чем вероятно, по крайней мере для меня это темный лес), то хотя бы должно быть понятно, что создание дампа с обезличенными данными – это не просто замена имени Сергей Сергеевич на Иван Иванович (или Дениз Льюис о Джоне Смите), здесь нужен более серьезный подход. Еще пара источников по той же теме: • Рекомендации Министерства здравоохранения и социальных служб США: Руководство относительно методов деидентификации защищенной медицинской информации в соответствии с Правилом конфиденциальности Закона о переносимости и подотчетности медицинского страхования (HIPAA) .
• Канадский Рекомендации «Передовой практики» по управлению раскрытием обезличенной медицинской информации .
• Рекомендации Управления комиссара по информации Великобритании: Анонимизация: кодекс практики управления рисками защиты данных .
Ну и в заключение, если вы увидели, что руководитель проекта по интеграции медицинских систем выделил пару дней на создание тестовых данных, а в редких случаях вообще не выделил это в отдельную задачу, то есть риск пропустить весь проект. Сроки очень высоки именно из-за сложности создания тестовых данных в количестве, достаточном для проверки работоспособности медицинской системы.
По-хорошему, этот подпроект следует начинать вместе со стартом основного проекта.
Теги: #hl++ #CDA #CCD #ccr #деидентификация #тестовые данные #Тестирование ИТ-систем #Анализ и проектирование систем #ИТ-стандарты #Разработка систем связи
-
Ноутбук Acer Aspire Серии As5741G-434G50Mn
19 Oct, 24 -
Оптимизация Брендинга Мобильных Приложений
19 Oct, 24 -
Пилотный Выпуск Подкаста Appleinsider
19 Oct, 24 -
2 Проекта Ищут Друзей
19 Oct, 24
