Editar

Supervisión remota de pacientes

Azure Data Lake Storage
Azure Databricks
Azure Event Hubs
Azure Machine Learning
Azure Synapse Analytics
Power BI

Tanto los sistemas de salud como los hospitales o los consultorios médicos están cambiando a iniciativas de hospital domiciliario (que también se conoce como supervisión remota de los pacientes). La supervisión remota de los pacientes es un subconjunto de la atención médica en la que no solo se puede acceder a lo datos de actividad y fisiológicos del paciente, sino que también se pueden utilizar dispositivos de salud remotos que se ajusten a los parámetros del plan de atención individualizado.

En este artículo se proporcionan las instrucciones necesarias para diseñar una solución mediante Azure Health Data Services y dispositivos para la supervisión remota inteligente de los pacientes. La solución ayudará a aliviar muchos de los problemas de integración de dispositivos a los que se va a tener que enfrentar su organización al crear una solución de este tipo a escala.

Architecture

Architecture diagram of remote patient monitoring architecture using healthcare devices and Azure services.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

  1. Los dispositivos de los pacientes generan datos tanto fisiológicos como de su actividad. A continuación, los datos se extraen de los dispositivos. Para ello, se usa uno de los distintos SDK de código abierto (OSS) de Microsoft disponibles ingeridos por Azure Event Hubs.

  2. La plataforma Life365.health admite más de 300 dispositivos que generan datos fisiológicos y de actividad La API Life365 ingiere los datos fisiológicos y de actividad de los dispositivos de supervisión de los pacientes en Azure Event Hubs.

  3. El servicio de tecnologías médicas de Azure extrae las mediciones de los dispositivos desde Event Hubs, las transforma al formato FHIR Fast Healthcare Interoperability Resources (FHIR®) y las pasa al servicio Azure FHIR. El área de trabajo de Azure Health Data Services es un contenedor lógico para las instancias de servicio sanitario, como los servicios FHIR y de tecnologías médicas.

  4. El área de trabajo de Azure Health Data Services envía mensajes de notificación a los suscriptores de eventos cuando se crea, actualiza o elimina un recurso de FHIR en el servicio Azure FHIR. Las notificaciones se pueden enviar a varios puntos de conexión para desencadenar la automatización, lo que incluye los flujos de trabajo de inicio o el envío de mensajes tanto de correo electrónico como de texto.

  5. Las canalizaciones de Análisis de FHIR exportan incrementalmente datos de FHIR no anonimizados a Azure Data Lake, lo que hace que estén disponibles para el análisis con varios servicios de datos de Azure. Los datos exportados también se pueden anonimizar con herramientas como las herramientas de código abierto de Microsoft para la anonimización de datos de salud. La anonimización predeterminada se basa en el método HIPAA Safe Harbor, que se puede ampliar y modificar según sea necesario.

    Importante

    Los datos de FHIR exportados en este flujo de datos son sin procesar, lo que incluye información de PHI. El proceso de falta de identificación se puede usar para quitar identificadores personales de los datos con fines de investigación o uso compartido. Si desea conjuntos de datos sin identificador, debe tomar las medidas necesarias para anonimizar los datos antes de exportarlos, para lo que puede usar una herramienta como la mencionada anteriormente.

  6. Un análisis adicional de los datos de FHIR en los formatos Parquet y JSON se realiza mediante grupos de Spark en los servicios Azure Synapse, Azure Databricks y Azure Machine Learning (ML).

  7. Las vistas SQL se crean en los grupos de SQL sin servidor en Azure Synapse. Se crea una vista SQL para cada recurso de FHIR basado en los archivos Parquet de Azure Data Lake. En función de estas vistas, los ingenieros de datos y los desarrolladores pueden escribir SQL nativo en Microsoft SQL Management Studio, o cualquier otro editor de SQL, para consultar los recursos de FHIR.

  8. Power BI y el conector de Power Query para FHIR se usan para importar y dar forma a los datos directamente desde el punto de conexión de FHIR Service API. Power BI también ofrece conectores Parquet y SQL para acceder al recurso de FHIR directamente en formato Parquet o a través de las vistas SQL en Synapse.

Componentes

Dispositivos

Dispositivos de consumidor

Microsoft proporciona SDK de código abierto para facilitar la transferencia de datos de varios dispositivos de consumidor para que los ingiera Azure Event Hubs:

Dispositivos médicos compatibles con Life365.health

La plataforma Life365.health se integra con más de 300 dispositivos de supervisión Bluetooth para la ingesta por parte de Azure Event Hubs. Los dispositivos abarcan varias categorías y OEM, que van desde espirómetros, termómetros, básculas, recordatorios de píldoras, seguidores de actividad, medidores de glucosa en sangre, tensiómetros, EKG/ECG, doppler fetales, monitores de frecuencia cardíaca, oxímetros de pulso, controladores del sueño, etc. La aplicación Life365 también permite la grabación manual de las lecturas tomadas de dispositivos que no usan la tecnología Bluetooth. Esta arquitectura utiliza Life365 API para ingerir las mediciones de los dispositivos Life365 en Event Hubs.

Otros

Aunque las opciones anteriores ayudan a facilitar la tarea, esta arquitectura admite orígenes de datos similares que se pueden ingerir de forma segura en Event Hubs, directa o indirectamente, a través de una API intermedia.

Servicios de Azure (recopilación y almacenamiento de datos)

  • Azure Event Hubs: un servicio de ingesta de datos en tiempo real y totalmente administrado que es sencillo, confiable y escalable. Transmite millones de eventos por segundo desde cualquier origen para compilar canalizaciones de datos dinámicos y responder inmediatamente a los desafíos empresariales. En esta arquitectura se usa para recopilar y agregar los datos del dispositivo para transferirlos a Azure Health Data Services.

  • Azure Health Data Services es un conjunto de servicios de API administrados basados en estándares abiertos y marcos que permiten a los flujos de trabajo mejorar la atención sanitaria y ofrecen soluciones de atención sanitaria escalables y seguras. Entre los servicios que se usan en esta arquitectura se incluyen los siguientes:

    • Área de trabajo de Azure Health Data Services: proporciona un contenedor para las restantes instancias de Azure Health Data Services, lo que crea un límite de cumplimiento (HIPAA, HITRUST) en el que puede viajar la información sanitaria protegida.

    • Servicio Azure FHIR: facilita el almacenamiento e intercambio seguro de información sanitaria protegida (PHI) en la nube. Los datos del dispositivo se transforman en recursos de observación basados en FHIR que admiten la supervisión remota de los pacientes.

    • Servicio detecnologías médicas de Azure: una piedra angular de Microsoft Cloud for Healthcare, que se usa para admitir la supervisión remota de pacientes. MedTech es una plataforma como servicio (PaaS) que permite recopilar datos casi en tiempo real de diversos dispositivos médicos y convertirlos en un formato de servicio compatible con FHIR, así como almacenarlos en un servicio FHIR. Las funcionalidades de traducción de los datos de los dispositivos del servicio de tecnologías médicas permiten transformar una amplia variedad de datos en un formato de FHIR unificado que proporciona administración segura de datos de salud en un entorno en la nube.

      El servicio de tecnologías médicas es importante para la supervisión remota de pacientes, ya es posible que sea difícil acceder o analizar a los datos de salud cuando proceden de dispositivos, sistemas o formatos diversos o incompatibles. El hecho de que no se pueda acceder con facilidad a la información médica puede ser una barrera para obtener información clínica y el plan de atención sanitaria de un paciente. La capacidad de traducir datos de salud en un formato de FHIR unificado permite al servicio de tecnologías médicas vincular correctamente dispositivos, datos de salud, laboratorios y atención remota en persona. Como resultado, esta funcionalidad puede facilitar el descubrimiento de información clínica importante y la captura de tendencias, lo que supone un apoyo para el médico, el equipo de atención, el paciente y la familia. También puede ayudar a establecer conexiones a nuevas aplicaciones de los dispositivos y a habilitar proyectos de investigación avanzados. Al igual que los planes de asistencia pueden individualizarse para cada caso de uso, los escenarios de supervisión remota de pacientes y los casos de uso pueden variar en función de las necesidades individuales.

  • Azure Event Grid: el servicio de eventos de Azure Health Data Services genera eventos cada vez que se crea, actualiza o elimina un recurso de FHIR (CUD). Azure Event Grid puede difundir estos eventos a los consumidores de nivel inferior para actuar en datos basados en eventos.

Servicios y herramientas de Azure (análisis de datos)

  • Canalizaciones de análisis de FHIR: un proyecto de software de código abierto que se usa para compilar componentes y canalizaciones para rectangularizar y mover datos de FHIR desde servidores de Azure FHIR hasta Azure Data Lake. En esta arquitectura, los datos se convierten a los formatos JSON (notación de objetos JavaScript) y Parquet, lo que hace que estén disponible para el análisis con varios servicios de datos de Azure.

  • Herramientas para la anonimización de datos de salud: un proyecto de software de código abierto respaldado por el equipo de Microsoft Healthcare ayuda a anonimizar datos sanitarios, locales o en la nube, para su uso secundario, como la investigación, salud pública, etc. El motor principal de anonimización usa un archivo de configuración para especificar distintos parámetros, así como métodos de anonimización para los distintos elementos de datos y tipos de datos.

  • Azure Synapse Analytics: servicio de análisis ilimitado que combina la integración de datos, el almacenamiento de datos empresariales y el análisis de macrodatos. Este servicio ofrece la libertad de consultar los datos como prefiera, ya sea sin servidor o con opciones dedicadas, a escala. Azure Synapse reúne estos mundos con una experiencia unificada para ingerir, explorar, preparar, transformar, administrar y servir datos para las necesidades inmediatas de inteligencia empresarial y aprendizaje automático.

  • Grupos de Apache Spark: Apache Spark es un marco de procesamiento paralelo que admite el procesamiento en memoria para mejorar el rendimiento de aplicaciones de análisis de macrodatos. Apache Spark en Azure Synapse Analytics es una de las implementaciones de Microsoft de Apache Spark en la nube. Azure Synapse facilita la creación y la configuración de un grupo de Apache Spark sin servidor en Azure. Los grupos de Spark en Azure Synapse son compatibles con Azure Storage y Azure Data Lake Storage Generation 2. Por lo tanto, puede usar grupos de Spark para procesar los datos almacenados en Azure.

  • Azure Databricks: plataforma de análisis de datos optimizada para la plataforma de servicios en la nube de Microsoft Azure. Databricks proporciona una plataforma unificada de análisis para ingenieros de datos, científicos de datos e ingenieros de aprendizaje automático. Se ofrecen tres entornos para desarrollar aplicaciones que consumen muchos datos: Databricks SQL, Databricks Ciencia de datos e ingeniería y Databricks Machine Learning.

  • Azure Machine Learning: es un servicio en la nube de Azure que permite acelerar y administrar el ciclo de vida de los proyectos de aprendizaje automático. Los profesionales de aprendizaje automático, científicos de datos e ingenieros pueden usarlo en sus flujos de trabajo diarios: entrenamiento e implementación de modelos y administración de MLOps. Puede crear un modelo en Azure Machine Learning o usar un modelo creado a partir de una plataforma de código abierto, como Pytorch, TensorFlow o Scikit-learn. Las herramientas de MLOps le ayudan a supervisar, volver a entrenar y volver a implementar modelos.

  • Power BI: proporciona análisis de autoservicio a escala empresarial, lo que le permite:

    • Crear una referencia cultural controlada por datos con inteligencia empresarial para todos.
    • Para realizar un análisis más profundo de los datos de FHIR es preciso mantener seguros los datos con las funcionalidades de seguridad de datos líderes del sector, como el etiquetado de confidencialidad, el cifrado de un extremo a otro y la supervisión del acceso en tiempo real.

  • Estos son los conectores de Power Query que se usan con Power BI:

  • SQL Server Management Studio: aplicación de escritorio que se usa para crear consultas SQL nativas en almacenes de datos SQL, como grupos de SQL de Azure Synapse Analytics.

Alternativas

Life365.health

La ventaja de Life365.health es que, con un punto de integración, es posible insertar mediciones desde una amplia gama de dispositivos del ecosistema de Life365 en Azure Health Data Services. Existen otras API de dispositivos ponibles, como Garmin Activity API y Polar AccessLink API, para las que se puede lograr un patrón de integración similar. Sin embargo, estas API son exclusivas para las mediciones de los dispositivos de sus propios fabricantes, como Garmin y Polar, respectivamente.

Tanto los dispositivos como los pacientes deben definirse, vincularse y sincronizarse entre Azure Health Data Services y life365 API. Esta configuración se puede lograr mediante la sincronización de los identificadores de paciente y dispositivo entre Azure Health Data Services y Life365 API. En esencia, en primer lugar se crean un paciente y dispositivo, y se vinculan en el servicio Azure FHIR. Luego, se crean y se vinculan el paciente y el dispositivo correspondientes en Life365 API. Luego, los identificadores de los pacientes y dispositivos, creados primero en Azure Health Data Services, se actualizarán como identificadores externos en las entidades de paciente y dispositivo respectivas en Life365 API.

Microsoft Cloud for HealthCare

Esta carga de trabajo de ejemplo aborda una forma de implementar una solución de supervisión remota de pacientes. Microsoft Cloud for Healthcare también proporciona una solución de supervisión remota de pacientes. Para más información sobre esa solución, consulte la visita guiada por la supervisión remota de pacientes.

Detalles del escenario

En la actualidad hay infinidad de dispositivos médicos y ponibles o de consumidor. Para acceder a las mediciones o lecturas de los dispositivos, muchos de los dispositivos de supervisión doméstica (como tensiómetros, báscula, etc.) cuentan con conectividad Bluetooth (como Bluetooth de bajo consumo u otras versiones anteriores del estándar Bluetooth). También hay dispositivos ponibles de consumidor, así como dispositivos domésticos más avanzados, que proporcionan conectividad de API para acceder a las mediciones de los dispositivos. En este caso, los dispositivos pueden sincronizar las lecturas directamente con la API (WiFi habilitado) o conectarse a una aplicación móvil en un teléfono inteligente (a través de Bluetooth), lo que permite que la aplicación sincronice la lectura con la API.

Declaración del problema

Dada la amplia gama de dispositivos médicos ponibles y domésticos, y las opciones de conectividad (desde Bluetooth a la especificación de API), multiplicadas por el número de pacientes que hay en la organización sanitaria, la integración y orquestación de datos pueden convertirse en una tarea desalentadora.

Posibles casos de uso

  • Ensayos e investigaciones clínicos: ayude a los equipos de investigación clínica a integrar y ofrecer una amplia gama de dispositivos médicos domésticos y ponibles al participante del estudio. En otras palabras, ofrezca una opción cercana a Bring-Your-Own-Device (BYOD) a los participantes del estudio.

  • Análisis de la ciencia de datos y de la salud de la población: los datos fisiológicos y de actividad estarán disponibles en el formato estándar de FHIR del sector, así como otros formatos de datos de código abierto (JSON y Parquet). Además del formato de datos, se proporcionan conectores nativos para ayudar en el análisis y la transformación de datos. Inclusión de conectores como el conector de Power BI para FHIR, las vistas de SQL sin servidor de Synapse y los clústeres de Spark en Synapse.

    Esta solución también proporciona un método con parámetros para anonimizar el conjunto de datos con fines de investigación no identificados. Estos "datos de uso secundario" se pueden analizar y usar para encontrar los procedimientos recomendados y admitir flujos de trabajo basados en la evidencia clínica. Las observaciones almacenadas en el servidor de FHIR se pueden usar para buscar variaciones y flujos de trabajo que promuevan los mejores resultados y prácticas.

  • Habilitar proveedores sanitarios: los proveedores podrán:

    • obtener mejor información del estado de salud del paciente
    • crear modelos proactivos de atención sanitaria digital para la atención médica preventiva
    • realizar acciones con mayor información basándose en los indicadores o notificaciones fisiológicos
    • proporcionar rutas para el reembolso de la supervisión fisiológica remota

  • Cuestionarios de resultado informado por el paciente (PRO) y atención controlada por PRO: el uso de eventos y cuestionarios de PRO permiten crear planes de atención médica individualizados y flujos de trabajo de varianza de la atención médica. El paciente puede tener más autonomía y control sobre el plan de atención médica individualizado, lo que facilita su adopción y uso sostenido. La atención médica controlada por PRO también puede ser útil para resolver la brecha en la educación y en los resultados de los pacientes. Al vincular los cuestionarios educativos y los resultados informados por los pacientes, se puede usar RPM para apoyar la medicación, el tratamiento o la atención de seguimiento, para responder preguntas como:

    • ¿Toman los pacientes su BP correctamente?
    • ¿Se usa la escala en el momento y con la frecuencia correctos?
    • ¿Enlazamos resultados informados por los pacientes para la adopción de pacientes y el planeamiento de la atención médica individualizada?

    En el caso de los pacientes que usan dispositivos iOS, se pueden compilar aplicaciones de cuestionario mediante Apple ResearchKit. Azure Event Hubs ingiere los datos del cuestionario y los pone a disposición del usuario a través del servicio FHIR, como la actividad y los datos fisiológicos del paciente del dispositivo.

  • Permitir varios tipos de dispositivos de salud y que estos sean más precisos: use dispositivos médicos domésticos para generar datos de salud casi en tiempo real que permitan la ingesta y el análisis de datos.

Consideraciones

Estas consideraciones son los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

La disponibilidad de información y datos clínicos es fundamental para muchas organizaciones sanitarias. Estas son las distintas formas de minimizar el tiempo de inactividad de los servicios de Azure indicados en esta solución:

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

A menudo, los datos sanitarios incluyen información sanitaria protegida confidencial (PHI) e información personal. Los siguientes recursos están disponibles para proteger estos datos:

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Los precios de muchos de los componentes de Azure se pueden encontrar en la Calculadora de precios de Azure. En última instancia, los precios de esta solución se basan en factores como:

  • Los servicios de Azure que se usan.
  • Volumen de datos, en términos del número de pacientes o dispositivos y del número de tipos de datos fisiológicos y de actividad que se ingieren.
  • Los requisitos de capacidad y rendimiento de Event Hubs.
  • Los recursos de proceso necesarios para realizar implementaciones y entrenamiento de aprendizaje automático, grupos de Synapse Spark y clústeres de Databricks.
  • La solución de visualización e informes, como Power BI.

Al implementar esta solución, tenga en cuenta la directiva de almacenamiento y retención de datos para la instancia de Azure Data Lake subyacente. Aproveche la administración del ciclo de vida de Azure Storage para proporcionar una forma automatizada de:

  • pasar los blobs de archivo al nivel de acceso esporádico
  • archivar niveles basados en la fecha y en que el archivo se modificó por última vez.

Para más información sobre los planes y precios de Life365.health, consulte la oferta de datos de conexión de Life365 API en Microsoft Azure Marketplace

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

Esta solución proporciona una arquitectura escalable casi en tiempo real para la supervisión remota de pacientes. Es importante reconocer el flujo de datos multicapa desde la interfaz entre los dispositivos y Life365 API, a la ingesta desde Life365 API y Azure Event Hubs, a la transformación del servicio de tecnologías médicas en Azure Health Data Service y, por último, a la exportación incremental y anonimización al formato de lago de datos. Por consiguiente, el flujo de datos se procesará casi en tiempo real y cualquier aplicación o integración de bajada debe diseñarse como tal. Sin embargo, el rendimiento de esta solución se puede escalar para que sirva a un gran número de dispositivos y pacientes a nivel empresarial.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Tecnologías y recursos importantes para la implementación de esta arquitectura: