Безопасное и эффективное управление данными о работоспособности критически важно для медицинских организаций. Службы данных Работоспособности Azure предоставляют мощную платформу, которую эти организации могут использовать для хранения, обработки и анализа конфиденциальных данных при соблюдении строгих стандартов безопасности и соответствия требованиям. Однако развертывание служб данных работоспособности в сложной корпоративной среде может быть сложной, если у вас нет эталонной архитектуры и руководства по реализации.
В этой статье представлен пример архитектуры, сопутствующая реализация примера и схема развертывания служб работоспособности с повышенной безопасностью и интеграции с другими службами Azure. Следуя рекомендациям, описанным в этом руководстве, можно улучшить возможность защиты данных о работоспособности.
Архитектура
Скачайте файл Visio для этой архитектуры.
Рабочий процесс
- Шлюз приложений Azure получает отдельные сообщения о быстром взаимодействии со здравоохранением (FHIR) (например, данные пациентов) по протоколу TLS с расширенной безопасностью, использующим поток учетных данных клиента. Шлюз приложений отправляет данные через Azure Управление API в службу FHIR служб работоспособности, где она сохраняется.
- Одновременно клиент может считывать те же данные FHIR по протоколу TLS через Шлюз приложений и Управление API.
- Для массовой обработки данных Шлюз приложений получает пакеты FHIR по протоколу TLS, использующего поток учетных данных клиента, и загружает данные в учетную запись хранения. Функция FHIR Loader Azure, интегрированная с виртуальной сетью, обрабатывает пакеты FHIR и загружает данные в службу FHIR.
- Если входящие данные хранятся в формате HL7 версии 2 или C-CDA, сначала его можно преобразовать в формат FHIR с помощью конечной точки $convert-данных в службе FHIR. Затем данные можно опубликовать в службе FHIR с помощью Шлюз приложений. Реестр контейнеров Azure, подключенный через частную конечную точку, используется для хранения с улучшенной безопасностью настраиваемых шаблонов Liquid для преобразования данных HL7 версии 2 или C-CDA в данные FHIR. Реестр контейнеров показан на схеме архитектуры, но преобразование
$convert-dataHL7 версии 2 / C-CDA в FHIR не реализуется примером шаблона реализации Bicep. - FHIR в агент синхронизации Synapse извлекает данные из службы FHIR (для приема данных через отдельный или массовый поток данных), преобразует извлеченные данные в иерархические файлы Parquet и записывает их в Azure Data Lake Storage.
- Azure Synapse Analytics использует бессерверный пул SQL или Spark для подключения к Data Lake Storage для запроса и анализа данных FHIR. Azure Synapse Analytics отображается на схеме архитектуры, но она не реализована шаблоном реализации Bicep.
- Виртуальная сеть концентратора содержит виртуальную машину и узел Бастиона Azure, чтобы обеспечить расширенный доступ к конфигурации службы FHIR. Администраторы и операторы также могут использовать виртуальную машину jumpbox для тестирования конечных точек службы FHIR без передачи Шлюз приложений и массовой загрузки данных FHIR вручную через службу хранилища Azure, обходя Шлюз приложений.
- Если вы устанавливаете локальное сетевое подключение через Azure ExpressRoute или VPN типа "сеть — сеть", локальные пользователи и службы могут напрямую получить доступ к службе FHIR через это подключение.
Примечание.
При необходимости можно добавить Брандмауэр веб-приложений (WAF) в Шлюз приложений, но существует известная проблема с неправильной обработкой объектов FHIR WAF и их обработкой как вредоносный код. Если вам нужен WAF, необходимо вручную изменить набор правил WAF, чтобы разрешить WAF работать с объектами FHIR.
Компоненты
Идентификатор Microsoft Entra — это мультитенантный облачный каталог и служба управления удостоверениями. Клиентские приложения регистрируются в идентификаторе Microsoft Entra и могут использоваться для доступа к службе FHIR служб работоспособности Azure.
Шлюз приложений — это платформа как услуга (PaaS) подсистема балансировки нагрузки уровня 7, которая может выступать в качестве службы обратного прокси-сервера. Внутренние и внешние пользователи получают доступ к API FHIR через Шлюз приложений через Управление API.
Управление API — это гибридная многооблачная платформа для управления API во всех средах. API FHIR можно импортировать в Управление API с помощью определения API Swagger. Вы можете использовать Управление API для регулирования входящих вызовов, проверки подлинности и авторизации пользователей и выполнения других задач.
Службы данных работоспособности — это набор управляемых служб API на основе открытых стандартов и платформ, которые позволяют рабочим процессам улучшить здравоохранение и предложить масштабируемые решения для обеспечения расширенной безопасности. Служба FHIR служб работоспособности развертывается с частной конечной точкой, чтобы обеспечить доступ только из виртуальной сети или внешних пользователей через Интернет через Шлюз приложений.
FHIR Loader — это решение Функции Azure, которое предоставляет службы для импорта пакетов FHIR (сжатых и не сжатых) и файлов NDJSON в службу FHIR.
Azure Key Vault — это служба Azure для хранения и доступа к секретам, ключам и сертификатам с улучшенной безопасностью. Key Vault обеспечивает безопасность и аудит доступа с поддержкой HSM с помощью элементов управления доступом на основе ролей, интегрированных с идентификатором Microsoft Entra. В этой архитектуре Key Vault хранятся учетные данные для перехода, Шлюз приложений сертификаты, сведения о службе FHIR и сведения о загрузчике FHIR.
Реестр контейнеров — это управляемая служба реестра , основанная на реестре Docker с открытым исходным кодом 2.0. В этой архитектуре он используется для размещения шаблонов Liquid . Пользовательская конечная
$convert-dataточка в службе FHIR можно использовать для преобразования данных о работоспособности из HL7 версии 2 и C-CDA в FHIR. Операция$convert-dataиспользует шаблоны Liquid из преобразователя FHIR для преобразования данных FHIR.FHIR в агент синхронизации Synapse — это приложение контейнера Azure, которое извлекает данные из сервера FHIR с помощью API ресурсов FHIR, преобразует его в иерархические файлы Parquet и записывает его в Data Lake Storage практически в реальном времени. Он также содержит скрипт для создания внешних таблиц и представлений в бессерверном пуле SQL Azure Synapse Analytics, который указывает на файлы Parquet. Хотя на схеме архитектуры показан агент синхронизации Synapse, Data Lake Storage и Azure Synapse Analytics, реализация Bicep в настоящее время не включает код для развертывания этих служб.
Брандмауэр Azure — это облачная интеллектуальная служба сетевого брандмауэра, которая обеспечивает защиту от угроз для облачных рабочих нагрузок в Azure. В этой архитектуре таблица маршрутов используется для маршрутизации исходящего трафика из виртуальной сети концентратора через Брандмауэр Azure, чтобы помочь обеспечить утечку данных. Аналогичным образом можно создать маршруты таблиц маршрутов и подключить их к периферийным подсетям виртуальной сети по мере необходимости, чтобы предотвратить кражу данных информации о здравоохранении (PHI).
Прыжковый ящик — это виртуальная машина Azure под управлением Linux или Windows, к которым могут подключаться администраторы и операторы с помощью протокола удаленного рабочего стола (RDP) или Secure Shell (SSH). Так как большинство служб (службы работоспособности, Управление API, Key Vault и другие) в этой архитектуре развертываются с частной конечной точкой, для внесения изменений конфигурации или тестирования этих служб требуется виртуальная машина перехода. К прыжку можно получить доступ только через Бастион Azure.
Бастион Azure позволяет подключаться к виртуальной машине с помощью браузера, портал Azure или через собственный клиент SSH/RDP на компьютере. В этой реализации Бастион Azure предоставляет расширенный доступ к виртуальной машине jumpbox.
Defender для облака и инициативы политики соответствия HIPAA и HITRUST помогают обеспечить соответствие развертывания инфраструктуры Azure требованиям к облачной безопасности Майкрософт и требованиям к соответствию отрасли здравоохранения.
Подробности сценария
Это решение содержит рекомендации по развертыванию служб работоспособности с повышенной безопасностью, приемом отдельных и массовых данных FHIR и сохранением данных в службе FHIR служб работоспособности.
Решение можно использовать для загрузки сообщений FHIR отдельно и массово в службу FHIR с помощью расширенного Шлюз приложений подключения.
Чтобы проанализировать данные FHIR и извлечь аналитические сведения, можно развернуть FHIR в агенте синхронизации Synapse, как показано на схеме. Azure Synapse Analytics может подключаться к Data Lake Storage для запроса и анализа данных FHIR.
Вы можете расширить решение для получения данных от медицинских и носимых устройств с помощью службы Health Data Services MedTech. Эту службу можно использовать для преобразования данных в формат FHIR и сохранения их в службе FHIR, чтобы получить аналитические сведения с помощью Azure Synapse Analytics.
Вы также можете расширить решение для приема данных без FHIR (HL7 версии 2 и C-CDA), преобразовать его в FHIR с помощью шаблонов Liquid, которые можно хранить в реестре контейнеров и сохранять их в службе FHIR.
Развертывание этого решения
Чтобы развернуть это решение, выполните действия, описанные в разделе "Начало работы".
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Умар Мохамед Усман | Главный инженер
Другие участники:
- Мик Альбертс | Технический писатель
- Шрини Падала | Старший инженер
- Соналика Рой | Старший инженер
- Виктор Сантана | Старший инженер
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Семинар по службам данных работоспособности Azure
- Начало работы со службами данных Работоспособности Azure
- FHIR-Bulk Loader и Export
- Создание сервера Swagger FHIR для Управление API
- Использование преобразователя FHIR для преобразования данных HL7 версии 2 и C-CDA