Изменить

Поделиться через

Удаленный мониторинг пациентов

Azure Data Lake Storage
Azure Databricks
Центры событий Azure
Машинное обучение Azure
Azure Synapse Analytics
Power BI

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

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

Архитектура

Схема архитектуры удаленного мониторинга пациентов с помощью медицинских устройств и служб Azure.

Скачайте файл Visio для этой архитектуры.

Поток данных

  1. Устройства пациентов создают активность и физиологические данные. Затем данные извлекаются с устройств с помощью одного из доступных пакетов SDK с открытым исходным кодом (OSS) Майкрософт и приема Центры событий Azure.

  2. Платформа Life365.health поддерживает 300 и более поздних устройств, которые создают действия и физиологические данные API Life365, в Центры событий Azure приема действий и физиологических данных от устройств мониторинга пациентов.

  3. Служба Azure MedTech извлекает измерения устройств из Центров событий, преобразовав их в формат FHIR Fast Healthcare Interoperability Resources (FHIR®) и передает их в службу Azure FHIR. Рабочая область Служб работоспособности Azure — это логический контейнер для экземпляров служб здравоохранения, таких как службы FHIR и MedTech.

  4. Рабочая область Служб работоспособности Azure отправляет уведомления подписчикам событий при создании, обновлении или удалении ресурса FHIR в службе Azure FHIR. Уведомления можно отправлять в несколько конечных точек для активации автоматизации, включая запуск рабочих процессов или отправку сообщений электронной почты и текстовых сообщений.

  5. Конвейеры FHIR Analytics постепенно экспортируют неанонимизированные данные FHIR в Azure Data Lake, что делает его доступным для аналитики с различными службами данных Azure. Экспортированные данные также можно анонимизировать с помощью таких средств, как средства с открытым исходным кодом Майкрософт для анонимизации данных работоспособности. Анонимизация по умолчанию основана на методе HIPAA Safe Harbor , который можно расширить и изменить по мере необходимости.

    Внимание

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

  6. Дальнейший анализ данных FHIR в форматах Parquet и JSON выполняется с помощью пулов Spark в Службах Azure Synapse, Azure Databricks и Машинное обучение Azure (ML).

  7. Представления SQL создаются в бессерверных пулах SQL в Azure Synapse. Представление SQL создается для каждого ресурса FHIR на основе файлов Parquet в Azure Data Lake. На основе этих представлений инженеры данных и разработчики могут писать собственный SQL в Microsoft SQL Management Studio или любой другой редактор SQL, чтобы запросить ресурсы FHIR.

  8. Power BI и соединитель Power Query для FHIR используются для импорта и формирования данных непосредственно из конечной точки API службы FHIR. Power BI также предлагает соединители Parquet и SQL для доступа к ресурсу FHIR непосредственно в формате Parquet или через представления SQL в Synapse.

Компоненты

.

Потребительские устройства

Корпорация Майкрософт предоставляет пакеты SDK с открытым кодом для упрощения передачи данных с различных потребительских устройств для приема по Центры событий Azure:

Life365.health поддерживает медицинские устройства

Платформа Life365.health интегрирована с более чем 300 устройствами мониторинга Bluetooth для приема по Центры событий Azure. Устройства охватывают несколько категорий и изготовителей оборудования, начиная от спирометров, термометров, весовых шкал, напоминаний о таблетках, трекеров активности, счетчиков глюкозы крови, мониторов кровяного давления, EKG / ECG, допплеры плода, мониторы частоты пульса, пульсовые оксиметры, спящие трекеры и многое другое. Приложение Life365 также позволяет вручную записывать данные, полученные с устройств, отличных от Bluetooth. Эта архитектура использует API Life365 для приема измерений устройств из устройств Life365 в Центры событий.

Другое

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

Службы Azure (сбор и хранение данных)

  • Центры событий Azure — полностью управляемая служба приема данных в режиме реального времени, которая является простой, доверенной и масштабируемой. Получите возможность выполнять потоковую передачу миллионов событий в секунду из любого источника, чтобы создавать конвейеры динамических данных и мгновенно решать бизнес-задачи. В этой архитектуре используется для сбора и агрегирования данных устройства для передачи в службы данных Работоспособности Azure.

  • Службы данных работоспособности Azure — это набор управляемых служб API на основе открытых стандартов и платформ, позволяющих рабочим процессам улучшить здравоохранение и предложить масштабируемые и безопасные решения для здравоохранения. К службам, используемым в этой архитектуре, относятся:

    • Рабочая область Служб работоспособности Azure — предоставляет контейнер для других экземпляров Служб данных Работоспособности Azure, создавая границу соответствия (HIPAA, HITRUST), в которой защищенная информация о работоспособности может перемещаться.

    • Служба Azure FHIR позволяет безопасно хранить и обмениваться защищенными сведениями о работоспособности (PHI) в облаке. Данные устройства преобразуются в ресурсы наблюдения на основе FHIR для поддержки удаленного мониторинга пациентов.

    • Служба Azure MedTech — краеугольный камень Microsoft Cloud для здравоохранения, используемый для поддержки удаленного мониторинга пациентов. MedTech — это платформа как услуга (PaaS), которая позволяет собирать практически в реальном времени данные из различных медицинских устройств и преобразовывать их в формат службы, совместимой с FHIR, и хранить их в службе FHIR. Возможности преобразования данных устройств службы MedTech позволяют преобразовать различные данные в единый формат FHIR, обеспечивающий безопасное управление данными о работоспособности в облачной среде.

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

  • Сетка событий Azure — служба событий служб данных Azure Health Data Services создает события всякий раз, когда ресурс FHIR создается, обновляется или удаляется (CUD). Эти события могут передаваться Сетка событий Azure подчиненным потребителям, чтобы действовать на основе данных на основе событий.

Службы и средства Azure (аналитика данных)

  • Конвейеры FHIR Analytics — проект OSS, используемый для создания компонентов и конвейеров для прямоугольной обработки и перемещения данных FHIR с серверов Azure FHIR в Azure Data Lake. В этой архитектуре данные преобразуются в нотацию объектов JavaScript (JSON) и формат Parquet , что делает его доступным для аналитики с различными службами данных Azure.

  • Средства для анонимизации данных работоспособности — проект OSS, поддерживаемый командой Microsoft Healthcare, помогает анонимизировать данные здравоохранения, локальные или в облаке, для вторичного использования, таких как исследования, здравоохранение и многое другое. Ядро анонимизации использует файл конфигурации для указания различных параметров, а также методов анонимизации для различных элементов данных и типов данных.

  • Azure Synapse Analytics — это бесграничная служба аналитики, которая объединяет интеграцию данных, хранение корпоративных данных и аналитику больших данных. Эта служба позволяет запрашивать данные на удобных для вас условиях с использованием бессерверных или выделенных вариантов в большом масштабе. Azure Synapse объединяет эти возможности, предоставляя единый интерфейс для приема, изучения, подготовки, преобразования, контроля и обслуживания данных для насущных потребностей бизнес-аналитики и машинного обучения.

  • Пулы Apache Spark . Apache Spark — это платформа параллельной обработки, которая поддерживает обработку в памяти для повышения производительности приложений аналитики больших данных. Apache Spark в Azure Synapse Analytics — это одна из реализаций Apache Spark в облаке, предоставляемая корпорацией Майкрософт. Azure Synapse упрощает создание и настройку бессерверного пула Apache Spark в Azure. Пулы Spark в Azure Synapse совместимы со службой хранилища Azure и Azure Data Lake Storage 2-го поколения. Следовательно, пулы Spark можно использовать для обработки данных, хранящихся в Azure.

  • Azure Databricks — платформа аналитики данных, оптимизированная для платформы облачных служб Microsoft Azure. Databricks предоставляет единую платформу аналитики для аналитиков данных, инженеров данных, специалистов по обработке и анализу данных и инженеров машинного обучения. Для разработки приложений с интенсивным использованием данных предлагаются три среды: Databricks SQL, Databricks Обработка и анализ данных и инженерии и Databricks Машинное обучение.

  • Машинное обучение Azure — облачная служба Azure для ускорения жизненного цикла проекта машинного обучения и управления ими. Специалисты по работе с машинным обучением, специалисты по обработке и анализу данных и инженеры данных могут использовать его в повседневных рабочих процессах: обучении и развертывании моделей, а также управлении MLOps. Вы можете создать модель в Машинном обучении Azure или использовать модель, построенную на основе платформы с открытым кодом, например Pytorch, TensorFlow или scikit-learn. Средства MLOps помогают отслеживать, переучивать и повторно развертывать модели.

  • Power BI — обеспечивает самостоятельную аналитику в масштабе предприятия, позволяя выполнять следующие действия:

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

  • Соединители Power Query, используемые с Power BI, включают:

    • Соединитель источника данных Parquet — используется для доступа к данным файла Azure Data Lake Parquet.
    • Соединитель Power Query для FHIR — используется для импорта и формирования данных с сервера FHIR.
    • Соединитель источника данных SQL Azure Synapse Analytics, используемый для создания запросов SQL к Azure Synapse Analytics.

  • SQL Server Management Studio — классическое приложение, используемое для создания собственных запросов SQL к хранилищам данных SQL, таким как пулы SQL Azure Synapse Analytics.

Альтернативные варианты

Life365.health

Преимущество Life365.health заключается в том, что с одной точкой интеграции можно отправлять измерения из широкого спектра устройств в экосистему Life365 в службы данных Работоспособности Azure. Существуют другие интерфейсы API устройства, такие как API активности Garmin и API Polar AccessLink, для которых можно достичь аналогичного шаблона интеграции. Однако эти API являются эксклюзивными для измерения с устройств своих собственных производителей, таких как Garmin и Polar соответственно.

Устройства и пациенты должны быть определены, связаны и синхронизированы между службами данных Работоспособности Azure и API Life365. Эту конфигурацию можно достичь, синхронизируя идентификаторы пациентов и устройств между службами данных Работоспособности Azure и API Life365. В сущности, новый пациент и устройство сначала создаются и связаны в службе Azure FHIR. Затем соответствующий пациент и устройство создаются и связаны в API Life365. Затем идентификаторы пациентов и устройств, созданных в Службах данных работоспособности Azure, будут обновлены как внешние идентификаторы в соответствующих сущностях пациентов и устройств в API Life365.

Microsoft Cloud для HealthCare

В этом примере рабочая нагрузка рассматривается одним из способов реализации решения для удаленного мониторинга пациентов. Microsoft Cloud для здравоохранения также предоставляет решение для мониторинга удаленных пациентов. Дополнительные сведения об этом решении см. в интерактивном туре по мониторингу удаленных пациентов.

Подробности сценария

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

формулировка проблемы;

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

Потенциальные варианты использования

  • Клинические испытания и исследования — помощь группам клинических исследований интегрируются и предлагают широкий спектр внутренних и носимых медицинских устройств участнику исследования. Иными словами, предоставьте участникам исследования параметр quasi-Bring-Your-Own-Device (BYOD).

  • Аналитика работоспособности и работоспособности данных в области обработки и популяции. Действия и физиологические данные будут доступны в стандартном формате FHIR в отрасли, а также в других форматах данных с открытым исходным кодом (JSON и Parquet). Помимо формата данных, собственные соединители предоставляются для помощи в анализе и преобразовании данных. Включая соединители, такие как соединитель Power BI для FHIR, представления Synapse Serverless SQL и кластеры Spark в Synapse.

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

  • Включение поставщиков услуг здравоохранения. Поставщики смогут:

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

  • Отчеты о результатах пациентов (PRO) и pro-управляемый уход . Используя события и анкеты PRO, отдельные планы ухода и рабочие процессы дисперсии ухода можно создать. Пациент может иметь большую автономию и контроль над индивидуальный план ухода, который помогает внедрению и устойчивому использованию. Помощь на основе pro также может быть полезной в решении пробела в образовании и результатах пациентов. Связав анкеты образования и PROs, RPM можно использовать для поддержки лекарств, лечения и /или последующего ухода, отвечая на такие вопросы, как:

    • Правильно ли пациенты принимают их BP?
    • Используется ли масштабирование в нужное время и частоту?
    • Циклизуемся ли мы в PROS для внедрения пациентов и индивидуального планирования ухода?

    Для пациентов, использующих устройства iOS, приложения анкеты можно создавать с помощью Apple ResearchKit. Данные анкеты принимаются Центры событий Azure и предоставляются через службу FHIR так же, как активность пациентов устройства и физиологические данные.

  • Разрешите несколько типов и более точных устройств здравоохранения . Используйте медицинские и домашние медицинские устройства для создания данных о работоспособности практически в режиме реального времени для приема и анализа данных.

Рекомендации

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

Надежность

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

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

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

Медицинские данные часто включают конфиденциальную защищенную медицинскую информацию (PHI) и личную информацию. Для защиты этих данных доступны следующие ресурсы:

  • Data Lake Storage использует управление доступом на основе ролей Azure (RBAC) и списки управления доступом (ACL) для создания модели управления доступом

  • Службы данных работоспособности Azure — это коллекция защищенных управляемых служб с помощью идентификатора Microsoft Entra, глобального поставщика удостоверений, поддерживающего OAuth 2.0. При создании новой службы в рамках службы Azure для работы с медицинскими данными, ваши данные по умолчанию шифруются с помощью ключей, управляемых Майкрософт. Дополнительные сведения см. в статье "Проверка подлинности и авторизация для служб данных Работоспособности Azure".

  • Центры событий Azure обеспечивает шифрование неактивных данных с помощью шифрования служб служба хранилища Azure (SSE). Таким образом, правила брандмауэра IP-адресов можно применять на уровне пространства имен Центров событий. Можно также настроить доступ к частным конечным точкам и виртуальной сети .

  • Synapse RBAC расширяет возможности рабочих областей Azure RBAC для Synapse и их содержимого. Azure RBAC используется для управления пользователями, которые могут создавать, обновлять или удалять рабочую область Synapse и ее пулы SQL, пулы Apache Spark и среду выполнения интеграции.

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

Цены на многие компоненты Azure можно найти в калькуляторе цен Azure. В конечном счете, цены на это решение основаны на таких факторах, как:

  • Используемые службы Azure.
  • Объем данных с точки зрения количества пациентов или устройств, а также количества действий и физиологических типов данных, которые принимаются.
  • Требования к емкости и пропускной способности для Центров событий.
  • Вычислительные ресурсы, необходимые для обучения и развертывания машинного обучения, пулов Synapse Spark и кластеров Databricks.
  • Решение визуализации и создания отчетов, например Power BI.

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

  • переход больших двоичных объектов файлов до уровня холодного доступа
  • уровни архива на основе последнего изменения файла.

Дополнительные сведения о планах и ценах на Life365.health см . в предложении Api Connect Data в Microsoft Azure Marketplace.

Оптимизация производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".

Это решение предоставляет масштабируемую архитектуру почти в реальном времени для удаленного мониторинга пациентов. Важно признать многоуровневый поток данных из интерфейса между устройствами и API Life365, прием из API Life365 в API Life365 и Центры событий Azure, преобразование в службу MedTech в службе данных Работоспособности Azure и, наконец, к добавочному экспорту и анонимности в формате озера данных данных. Таким образом, поток данных будет обрабатываться практически в режиме реального времени, а все подчиненные приложения и (или) интеграции должны быть разработаны таким образом. Тем не менее, производительность этого решения может масштабироваться до обслуживания большого количества устройств и пациентов на корпоративном уровне.

  • Это решение использует Центры событий Azure в качестве основной точки приема. Масштабируемость центров событий можно управлять единицами пропускной способности, единицами обработки и единицами емкости. Таким образом, секционирование может помочь в обработке больших объемов событий в Центрах событий.

  • Функция автомасштабирования пула Apache Spark для Azure Synapse Analytics автоматически масштабирует количество узлов в экземпляре кластера вверх и вниз.

  • Машинное обучение Azure предлагает развертывание для вывода с процессорами GPU и Azure FPGAs, которые позволяют достичь низкой задержки для вывода в реальном времени.

Соавторы

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

Основные авторы:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Технологии и ресурсы, относящиеся к реализации этой архитектуры: