Как соответствовать требованиям HIPAA при тестировании программного обеспечения?

Отказ от ответственности . В статье рассматриваются только основные области тестирования программного обеспечения на соответствие HIPAA, а не такие элементы, как физические меры безопасности, такие как невозможность развертывания программного обеспечения на рабочих станциях с открытыми экранами. Кроме того, обратите внимание, что стратегия будет зависеть от требований приложения, то есть она не будет применима для всех приложений.

Медицинские организации становятся жертвами массовых утечек данных с угрожающей скоростью. Один из ярких примеров этого можно увидеть в случае атаки программы-вымогателя на региональный медицинский центр Юма, которая раскрыла данные более 700 000 человек еще в апреле 2022 года. Растущее число случаев утечки данных также видно из графика ниже.

Поскольку цифры с каждым годом становятся все более тревожными, медицинские организации обращаются к программному обеспечению, созданному с непревзойденными мерами защиты данных для хранения и передачи своих медицинских данных. Организации соблюдают все требования соответствия HIPAA, а также тратят много времени на обеспечение надежности и безопасности созданного программного обеспечения для здравоохранения .

Это уделяет большое внимание тестированию программного обеспечения, совместимому с HIPAA. Что произойдет, если вы не будете тестировать программное обеспечение для здравоохранения с упором на соответствие HIPAA? Несоответствие тестированию программного обеспечения HIPAA откроет приложение для утечки данных и его незаконного использования. Вдобавок к этому это приведет к суровым наказаниям со стороны Министерства здравоохранения и социальных служб США.

По этой причине вашей команде разработчиков программного обеспечения для здравоохранения необходимо уделять время созданию приложения, совместимого с HIPAA, уделяя повышенное внимание тестированию программного обеспечения.

В Appinventiv, в нашей роли компании-разработчика программного обеспечения для здравоохранения , мы успешно разработали, протестировали и развернули приложения для здравоохранения, затрагивающие множество заинтересованных сторон, без единого случая нарушения.

В этой статье мы обсудим различные способы проверки вашего приложения на соответствие HIPAA посредством тестирования. Но сначала давайте посмотрим, почему создание программного обеспечения, совместимого с HIPAA, становится все труднее.

Почему создать программное обеспечение, совместимое с HIPAA, сложно?

В то время как каждый поставщик медицинских услуг уделяет особое внимание безопасности, чтобы обеспечить соответствие HIPAA, сложность сектора такова, что иногда некоторые элементы остаются нерешенными. Вот что обычно происходит при отсутствии контрольного списка программного обеспечения, соответствующего требованиям HIPAA.

• Много данных для защиты

Прежде чем создавать структуру защиты данных, разработчики должны иметь полное представление о том, что представляет собой конфиденциальная информация. В системе здравоохранения оценка этого может быть затруднена, поскольку данные хранятся в разных форматах в разных местах, таких как физические места хранения, системы EHR, центры обработки данных, мобильные устройства, офисы поставщиков и т. д.

• Недостаток ресурсов для соответствия требованиям HIPAA

Создание программного обеспечения, действительно соответствующего HIPAA, требует добавления в команду юристов, системных архитекторов, экспертов по кибербезопасности и медицинских экспертов. Все они вкладывают в проект обширные знания и время, что не всегда возможно из-за фиксированной стоимости и сроков разработки приложения для здравоохранения .

• Несколько платформ доступа к данным

Все платформы в системе здравоохранения должны быть защищены едиными мерами безопасности. Однако больничная инфраструктура состоит из реальных и цифровых пользовательских конечных точек, центров обработки данных, серверов, облачных ресурсов и т. д. Чтобы создать единую инфраструктуру безопасности, необходимо изучить разработку MDM для защиты конфиденциальных данных.

• Снижение гибкости

Программное обеспечение, созданное с учетом множества требований безопасности, может быть жестким по своей природе, однако организациям здравоохранения нужна гибкость, чтобы иметь возможность управлять пациентами и врачами. Это приводит к ситуации, когда разработчикам приходится управлять гибкостью и соответствием требованиям HIPAA, не ставя под угрозу опыт здравоохранения.

• Необходимо переоценить реализацию HIPAA

Тестирование на соответствие требованиям HIPAA не заканчивается развертыванием приложения. Многочисленные элементы, такие как угрозы кибербезопасности, требования HIPAA и ИТ-потребности медицинских организаций, постоянно меняются, и для обеспечения соответствия вашего программного обеспечения вам потребуется проводить регулярные аудиты и обновлять документы.

Теперь, когда мы рассмотрели элементы, которые затрудняют создание приложения, совместимого с HIPAA, пришло время также рассмотреть решения, изучив области тестирования программного обеспечения на соответствие HIPAA, а затем способы ответа, каков процесс Тестирование на соответствие HIPAA?

Стратегии и области тестирования программного обеспечения HIPAA

Для простоты понимания мы обычно делим тестирование программного обеспечения на соответствие HIPAA на 5 ключевых областей. Знание этих областей важно для ответа. Как вы гарантируете, что программное обеспечение соответствует требованиям HIPAA?

Аутентификация пользователя

Как правило, аутентификация пользователя может быть любой из этих: на основе владения, например, удостоверения личности, на основе знаний, например, идентификатора пользователя/пароля, и на основе биометрических данных, например, отпечатков пальцев или сканирования лица. Тестирование программного обеспечения на этом фронте выходит за рамки обеспечения успешного входа в систему для каждой роли и изучает:

• Ошибка входа из-за –
  • Пустой идентификатор пользователя и пароль
  • Неверный идентификатор пользователя и пароль
  • Просроченный или заблокированный аккаунт
• Заблокированный аккаунт
• Войти успешно после смены пароля
• Время простоя входа в систему
• Данные для входа не сохраняются в памяти приложения

Кроме того, это помогает создать стандартную структуру данных теста, например, <PatientFirstName><PatientLastName><TestName><Date><Time>. Это поможет легко идентифицировать пользователей.

Раскрытие информации

Раскрытие информации обычно работает с двумя категориями: доступ на основе ролей и распределение пациентов. В первом случае пользователи группируются в логические классы с определенными уровнями доступа, а во втором супервизор назначает пациентов поставщику медицинских услуг на определенное время.

Будет полезно разработать тестовые случаи, в которых будет указано, кто может просматривать/изменять/добавлять/удалять информацию, к которой у них нет доступа. Кроме того, вы должны создать практику, при которой после удаления приложения вся информация EPHI должна быть удалена и удалена из системы. Надлежащее раскрытие информации должно быть ключевой частью контрольного списка программного обеспечения, отвечающего требованиям HIPAA.

Журналы аудита

Изучая часть контрольных журналов тестирования программного обеспечения HIPAA, следует обратить внимание на следующие факторы.

• Каждая запись в контрольном журнале должна содержать следующую информацию:
  • Дата и время действия
  • Id или имя пользователя, выполняющего действие
  • Уровень доступа пользователя
  • Идентификатор записи пациента, с которым произошло действие
  • Действие, которое было выполнено или предпринято
  • Конкретное событие, из которого оно было выполнено (например, оплата или составление карты пациента)
  • Местоположение или системный идентификатор, через который произошло действие

• Записи должны соответствовать требованиям безопасности программного обеспечения, а контрольный журнал должен быть легко отслежен для дальнейшего расследования.
• Записи не должны удаляться из контрольного журнала.
• Контрольный журнал должен быть предназначен для просмотра конкретными учетными записями пользователей.
• Все попытки нарушения безопасности должны отслеживаться в журнале аудита.
• Журнал аудита должен быть зашифрован.

Передача данных

Передача данных является еще одной ключевой областью тестирования на соответствие HIPAA, где необходимо обеспечить безопасность во время:

• Доступ к данным между физическими и мобильными устройствами, на которых установлено приложение
• Передача данных на внешнее устройство и местоположение
• Перемещение данных в автономное хранилище.

Во время передачи данных также важно отметить, что обычно данные будут зашифрованы (которые могут быть расшифрованы только авторизованными пользователями). Ниже приведены рекомендации по шифрованию данных, которые должны стать частью требований соответствия HIPAA.

• Защитите ключи шифрования, чтобы предотвратить использование системных данных неавторизованными пользователями.
• Шифруйте конфиденциальные данные независимо от того, где они хранятся внутри системы.
• Регулярно анализируйте производительность алгоритма при шифровании данных.

Информация о правильном использовании данных

Наконец, приложение должно предоставить подробную информацию об использовании данных перед доступом к ним. В зависимости от приложения это может быть страница справки для каждой операции, включающей EPHI, или создание обучающей версии приложения, которая позволяет пользователям увидеть, как работает программное обеспечение, прежде чем предоставлять доступ к накопительному EPHI.

Итак, вот 5 важнейших областей тестирования программного обеспечения на соответствие HIPAA, но как мы можем гарантировать, что оно применяется в процессе разработки приложений для здравоохранения?

Каковы шаги для достижения и поддержания соответствия требованиям HIPAA при тестировании программного обеспечения?

Давайте узнаем в нашем следующем разделе.

Шаги для достижения и поддержания соответствия HIPAA при тестировании программного обеспечения

В Appinventiv, когда мы создаем приложение для здравоохранения, мы делаем требования к программному обеспечению HIPAA частью сквозного цикла разработки, особенно тестирования. Вот несколько способов обеспечить то же самое.

1. Контроль доступа

В соответствии с требованиями соответствия HIPAA любому пользователю должен быть разрешен доступ только к той информации, которая ему необходима для выполнения конкретной задачи. Достижение этого строгого уровня контроля доступа может быть достигнуто с помощью следующих семи режимов:

• Список контроля доступа, который дает пользователю доступ к определенным модулям/приложениям/областям.
• Отличительное имя и номер для идентификации и отслеживания личности каждого пользователя внутри системы.
• Пользовательский доступ, требующий двухфакторной аутентификации для входа в систему.
• Доступ на основе ролей, который зависит от роли пользователя в поиске и определении прав доступа.
• Доступ на основе контекста, который ограничивает доступ к определенному времени или дате в определенной сети или информационной системе.
• Специальный процесс для чрезвычайной ситуации для сбора критической ePHI.
• Электронные процессы, обеспечивающие автоматический выход из электронного сеанса после заранее определенного времени бездействия.
• Зашифруйте и расшифруйте ePHI.

2. Тестирование на вменяемость

Первая часть протокола тестирования программного обеспечения HIPAA, которой мы следуем, — это проверка работоспособности, в ходе которой мы ищем дефекты в стандартах соответствия HIPAA приложения. Это включает в себя изучение таких областей, как -

• Для каждой роли или отношения с высоким риском мы проверяем, может ли пользователь определенной роли легко пройти аутентификацию, предоставлен ли доступ для просмотра, изменения и удаления или нулевой доступ к конкретной операции компонента приложения. После выполнения всех действий они записываются в журнал аудита.
• Шифрование проверяется для таких областей, как записи контрольного журнала и EPHI в базе данных.

3. Матрица ролей

Предполагая, что приложение использует доступ на основе ролей, становится важным определить роли в системе и уровень доступа, который они могут иметь в приложении. Этот шаг обычно выполняется путем общения с клиентами, которые сообщают нам об уровне риска на основе раскрытия информации, частоте использования, вероятности ошибки и влиянии ошибки.

Когда мы проводим тестирование работоспособности, подобная диаграмма помогает определить уровни риска, связанные с каждым отношением, и гарантировать, что проблемы будут обнаружены и устранены заблаговременно.

4. Тестовые случаи

Третий шаг, которому мы следуем при тестировании программного обеспечения на соответствие требованиям HIPAA, — это создание подробных тестовых сценариев, в которых движения пользователей разбиваются на уровни действий и результатов. Давайте подробно рассмотрим это на примере приложения для записи на прием к врачу.