В этой небольшой статье хотелось бы затронуть некоторые, может быть для кого-то не совсем очевидные, аспекты тестирования интерфейсов медицинских систем. И хотя чаще всего взаимодействие подобных систем строится на основе одного из протоколов Health Level 7 (HL7), это не обязательное условие, могут быть использованы и другие способы коммуникации (как пример, можно назвать ASTM Continuity of Care Records (CCR) до того, как он был адаптирован HL7 под названием CCD).
И так, после того как интерфейс между мед системами реализован, на следующем шаге необходимо провести ряд различных тестов направленных на проверку реализации бизнес-требований (acceptance testing или приёмочные испытания, кстати, статьи в Wiki на русском языке про этот тип тестов нет) и реализацию технологических требований (интеграционное тестирование и юнит-тестирование). Оба типа тестирования невозможны без тестовых данных. Данная статья как раз про один из аспектов создания тестовых данных для тестирования мед систем.
Чтобы проблему было легче понять, посмотрим, как это происходит в общем случае. Команда тестировщиков получает дамп базы из рабочей (production) системы. Эти данные состоят из трёх достаточно условных групп: непосредственно данные для тестирования, справочные данные тестов и справочные данные для приложения. Для проверки корректности работы программы (проверки реализации технологических требований), тестировщик может создать свои собственные фейковые данные, которые перекрывают все три типа.
Другие типы тестирования, такие как приёмочные испытания, интеграционное тестирование, тестирование нефункциональных требований (опять же, статьи в wiki на русском нет) требуют более сложных тестовых данных, а также достаточного объёма тестовых данных для тестирования производительности системы.
В случае с медицинскими системами (в том случае, когда это делается правильно, а не на коленках) возникает задача управления тестовыми данными при разработке и тестировании подобных систем с учётом соблюдения действующих законов и норм, направленных на защиту демографической и медицинской информации пациента от случайного или преднамеренного разглашения. Как раз для этого используется де-идентификация данных о чём я и хотел сказать в этой статье.
Де-идентификация информации пациентов крайне важна не только при разработке и тестировании мед систем, как может показаться на первый взгляд, но и при использовании в аналитических системах, о которых я писал в прошлый раз — (Public Health Information Networks и Clinical Research Support).
Вот лишь несколько причин, из-за которых необходима де-индетификация данных: ноутбуки разработчиков, жесткие диски или флэш-накопители могут быть потеряны или украдены; возможны хакерские атаки на не сильно защищённые компьютеры разработчиков, в том числе изнутри компании и много чего прочего.
Про реальные примеры можно почитать на сайте — databreachtoday.com — и хотя первая страница этого сайта наверняка будет другой, отличной от той, что вижу я в момент публикации этой статьи, более чем вероятно, хотя бы одна статья будет про мед данные или HIPAA или аналогичный акт.
Во всех выше перечисленных и не только этих случаях, регулирующие органы требуют немедленного уведомления, если произошла утечка или потеря персональных данных. Более того, в погоне за жаренными фактами, СМИ постараются раздуть потерю даже небольшого количества персональных данных до мировой проблемы (опять же, смотри выше приведённый сайт). Я имел возможность следить по газетным публикациям за группой мед аналитиков, которые всем составом были уволены и привлечены к суду, а через год восстановлены в правах с извинениями как раз из-за доступа к мед данным.
Прежде чем продолжать рассказ, небольшое домашнее задание. Одна компания утверждает, что приведённые ниже данные являются тестовыми:
Rhonda James; DOB: 08-Sep-1988; Address: 71 Ansubet Dr, Charleston, WV
Denise Lewis; DOB: 03-Mar-1976; Address: 23 Adams Chapel Rd, Mankato, MN
Rosemarie Hardy; DOB: 14-Nov-1985; Address: 310 Camp Creek Rd, Weston, MA
Похоже ли это на тестовые данные? Да, похоже. Однако, компания также утверждает, что это не просто тестовые данные, но и де-идентифицированные данные. Я взял WhitePages и сделал поиск по одному из имён и штату проживания. Оказалось, там есть несколько человек с такими данными. Домашний адрес не совпадает, но ведь всегда можно сказать, что человек переехал и т.п. Так что, до тех пор, пока какой-нибудь Rhonda или Denise или СМИ не обратят на это внимание, компания может спать спокойно, проблемы могут начаться потом.
Предположим, что вы решили сделать всё правильно и приготовить достаточный объём де-идентифицированных тестовых данных. (Опять же, речь идёт о мед системах и их взаимодействии, я не пытаюсь залезть в каким-то смежные области.) Прежде чем менеджер проекта или архитектор или самый главный тестировщик примет такое решение и бросится писать парсер для дампа базы, стоит учесть, что другие уже сталкивались с этим, долго думали и придумали разные подходы к созданию этих самых де-идентифицированных данных, такие как: data reduction, data modification, data suppression и прочее.
Для ознакомления предлагаю прочитать Tools for De-Identification of Personal Health Information написанную Ross Fraser и Don Willison. Даже если вы ни чего не поймёте (что более чем вероятно, по крайне мере для меня это тёмный лес), то, хотя бы, должно быть ясно, что создание дампа с де-идентифицированными данными это не просто замена имени Сергей Сергеевич на Иван Иванович (или Denise Lewis на John Smith), должен быть более серьёзный подход.
Пара других источников по этому же поводу:
• Руководство от US Department of Health and Human Services: Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.
• Канадский “Best Practice” guidelines for Managing the Disclosure of De-Identified Health Information.
• Руководство от UK Information Commissioner's Office: Anonymisation: managing data protection risk code of practice.
Ну и в заключении, если вы увидели, что менеджер проектов по интеграции мед систем выделил на создание тестовых данных пару дней, а в редких случаях вообще не выделил это в отдельную задачу, то риск пролететь все сроки сдачи проекта очень высок именно в виду сложности создания тестовых данных в объёме достаточном для тестирования производительности мед системы. По-хорошему, этот под-проект надо начинать вместе с началом основного проекта.
И так, после того как интерфейс между мед системами реализован, на следующем шаге необходимо провести ряд различных тестов направленных на проверку реализации бизнес-требований (acceptance testing или приёмочные испытания, кстати, статьи в Wiki на русском языке про этот тип тестов нет) и реализацию технологических требований (интеграционное тестирование и юнит-тестирование). Оба типа тестирования невозможны без тестовых данных. Данная статья как раз про один из аспектов создания тестовых данных для тестирования мед систем.
Чтобы проблему было легче понять, посмотрим, как это происходит в общем случае. Команда тестировщиков получает дамп базы из рабочей (production) системы. Эти данные состоят из трёх достаточно условных групп: непосредственно данные для тестирования, справочные данные тестов и справочные данные для приложения. Для проверки корректности работы программы (проверки реализации технологических требований), тестировщик может создать свои собственные фейковые данные, которые перекрывают все три типа.
Другие типы тестирования, такие как приёмочные испытания, интеграционное тестирование, тестирование нефункциональных требований (опять же, статьи в wiki на русском нет) требуют более сложных тестовых данных, а также достаточного объёма тестовых данных для тестирования производительности системы.
В случае с медицинскими системами (в том случае, когда это делается правильно, а не на коленках) возникает задача управления тестовыми данными при разработке и тестировании подобных систем с учётом соблюдения действующих законов и норм, направленных на защиту демографической и медицинской информации пациента от случайного или преднамеренного разглашения. Как раз для этого используется де-идентификация данных о чём я и хотел сказать в этой статье.
Де-идентификация информации пациентов крайне важна не только при разработке и тестировании мед систем, как может показаться на первый взгляд, но и при использовании в аналитических системах, о которых я писал в прошлый раз — (Public Health Information Networks и Clinical Research Support).
Вот лишь несколько причин, из-за которых необходима де-индетификация данных: ноутбуки разработчиков, жесткие диски или флэш-накопители могут быть потеряны или украдены; возможны хакерские атаки на не сильно защищённые компьютеры разработчиков, в том числе изнутри компании и много чего прочего.
Про реальные примеры можно почитать на сайте — databreachtoday.com — и хотя первая страница этого сайта наверняка будет другой, отличной от той, что вижу я в момент публикации этой статьи, более чем вероятно, хотя бы одна статья будет про мед данные или HIPAA или аналогичный акт.
Во всех выше перечисленных и не только этих случаях, регулирующие органы требуют немедленного уведомления, если произошла утечка или потеря персональных данных. Более того, в погоне за жаренными фактами, СМИ постараются раздуть потерю даже небольшого количества персональных данных до мировой проблемы (опять же, смотри выше приведённый сайт). Я имел возможность следить по газетным публикациям за группой мед аналитиков, которые всем составом были уволены и привлечены к суду, а через год восстановлены в правах с извинениями как раз из-за доступа к мед данным.
Прежде чем продолжать рассказ, небольшое домашнее задание. Одна компания утверждает, что приведённые ниже данные являются тестовыми:
Rhonda James; DOB: 08-Sep-1988; Address: 71 Ansubet Dr, Charleston, WV
Denise Lewis; DOB: 03-Mar-1976; Address: 23 Adams Chapel Rd, Mankato, MN
Rosemarie Hardy; DOB: 14-Nov-1985; Address: 310 Camp Creek Rd, Weston, MA
Похоже ли это на тестовые данные? Да, похоже. Однако, компания также утверждает, что это не просто тестовые данные, но и де-идентифицированные данные. Я взял WhitePages и сделал поиск по одному из имён и штату проживания. Оказалось, там есть несколько человек с такими данными. Домашний адрес не совпадает, но ведь всегда можно сказать, что человек переехал и т.п. Так что, до тех пор, пока какой-нибудь Rhonda или Denise или СМИ не обратят на это внимание, компания может спать спокойно, проблемы могут начаться потом.
Предположим, что вы решили сделать всё правильно и приготовить достаточный объём де-идентифицированных тестовых данных. (Опять же, речь идёт о мед системах и их взаимодействии, я не пытаюсь залезть в каким-то смежные области.) Прежде чем менеджер проекта или архитектор или самый главный тестировщик примет такое решение и бросится писать парсер для дампа базы, стоит учесть, что другие уже сталкивались с этим, долго думали и придумали разные подходы к созданию этих самых де-идентифицированных данных, такие как: data reduction, data modification, data suppression и прочее.
Для ознакомления предлагаю прочитать Tools for De-Identification of Personal Health Information написанную Ross Fraser и Don Willison. Даже если вы ни чего не поймёте (что более чем вероятно, по крайне мере для меня это тёмный лес), то, хотя бы, должно быть ясно, что создание дампа с де-идентифицированными данными это не просто замена имени Сергей Сергеевич на Иван Иванович (или Denise Lewis на John Smith), должен быть более серьёзный подход.
Пара других источников по этому же поводу:
• Руководство от US Department of Health and Human Services: Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.
• Канадский “Best Practice” guidelines for Managing the Disclosure of De-Identified Health Information.
• Руководство от UK Information Commissioner's Office: Anonymisation: managing data protection risk code of practice.
Ну и в заключении, если вы увидели, что менеджер проектов по интеграции мед систем выделил на создание тестовых данных пару дней, а в редких случаях вообще не выделил это в отдельную задачу, то риск пролететь все сроки сдачи проекта очень высок именно в виду сложности создания тестовых данных в объёме достаточном для тестирования производительности мед системы. По-хорошему, этот под-проект надо начинать вместе с началом основного проекта.