Editar

Monitorização remota de doentes

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

Sistemas de saúde, hospitais e grandes consultórios médicos estão mudando para iniciativas hospitalares em casa (também conhecidas como monitoramento remoto de pacientes). O monitoramento remoto de pacientes é um subconjunto de cuidados clínicos onde a atividade dos pacientes e os dados fisiológicos podem ser acessados e entregues usando dispositivos de saúde remotos de acordo com os parâmetros do plano de cuidados individualizados.

Este artigo fornece orientação sobre como projetar uma solução usando os Serviços de Dados de Saúde do Azure e dispositivos para monitoramento remoto inteligente de pacientes. A solução ajudará a aliviar muitos dos desafios de integração de dispositivos que sua organização deve enfrentar ao criar uma solução em escala.

Arquitetura

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

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

  1. Os dispositivos dos pacientes geram atividade e dados fisiológicos. Os dados são extraídos dos dispositivos usando um dos SDKs de código aberto (OSS) disponíveis da Microsoft e ingeridos pelos Hubs de Eventos do Azure.

  2. A plataforma Life365.health suporta 300+ dispositivos que geram atividade e dados fisiológicos A API Life365 ingere a atividade e os dados fisiológicos dos dispositivos de monitoramento do paciente nos Hubs de Eventos do Azure.

  3. O serviço MedTech do Azure extrai as medições do dispositivo dos Hubs de Eventos, transformando-as em FHIR (Fast Healthcare Interoperability Resources) no formato FHIR,® e passa-as para o serviço FHIR do Azure. O espaço de trabalho dos Serviços de Dados de Saúde do Azure é um contêiner lógico para instâncias de serviços de saúde, como os serviços FHIR e MedTech.

  4. O espaço de trabalho dos Serviços de Dados de Saúde do Azure envia mensagens de notificação aos subscritores de eventos quando um recurso FHIR é criado, atualizado ou eliminado no serviço FHIR do Azure. As notificações podem ser enviadas para vários pontos de extremidade para acionar a automação, incluindo iniciar fluxos de trabalho ou enviar e-mails e mensagens de texto.

  5. Os FHIR Analytics Pipelines exportam incrementalmente dados FHIR não anonimizados para o Azure Data Lake, disponibilizando-os para análise com vários serviços de dados do Azure. Os dados exportados também podem ser anonimizados aproveitando ferramentas como as Ferramentas de código aberto da Microsoft para Anonimização de Dados de Saúde. A anonimização padrão é baseada no método HIPAA Safe Harbor , que pode ser estendido e modificado conforme necessário.

    Importante

    Os dados FHIR exportados neste fluxo de dados são brutos, o que inclui informações PHI. O processo de desidentificação pode ser utilizado para remover identificadores pessoais dos dados para fins de investigação ou partilha. Se desejar conjuntos de dados desidentificados , deve tomar medidas para anonimizar os dados antes de exportá-los, usando uma ferramenta como a mencionada acima.

  6. Uma análise mais aprofundada dos dados FHIR nos formatos Parquet e JSON é feita usando pools do Spark nos serviços Azure Synapse, Azure Databricks e Azure Machine Learning (ML).

  7. As Exibições SQL são criadas nos pools SQL sem servidor no Azure Synapse. Uma exibição SQL é criada para cada recurso FHIR com base nos arquivos Parquet no Azure Data Lake. Com base nessas exibições, os engenheiros de dados e desenvolvedores podem escrever SQL nativo no Microsoft SQL Management Studio, ou em qualquer outro editor SQL, para consultar os recursos FHIR.

  8. O Power BI e o conector do Power Query para FHIR são usados para importar e moldar dados diretamente do ponto de extremidade da API do Serviço FHIR. O Power BI também oferece conectores Parquet e SQL para acessar o recurso FHIR diretamente no formato Parquet ou por meio das Exibições SQL no Synapse.

Componentes

Dispositivos

Dispositivos de consumo

A Microsoft fornece SDKs de código aberto para facilitar a transferência de dados de vários dispositivos de consumo para ingestão pelos Hubs de Eventos do Azure:

Dispositivos médicos suportados Life365.health

A plataforma Life365.health está integrada com mais de 300 dispositivos de monitorização Bluetooth para ingestão pelos Hubs de Eventos do Azure. Os dispositivos abrangem várias categorias e OEMs, que vão desde espirômetros, termômetros, balanças de peso, lembretes de pílulas, rastreadores de atividade, medidores de glicose no sangue, monitores de pressão arterial, ECG / ECG, dopplers fetais, monitores de frequência cardíaca, oxímetros de pulso, rastreadores de sono e muito mais. O aplicativo Life365 também permite a gravação manual de leituras tiradas de dispositivos sem Bluetooth. Essa arquitetura utiliza a API Life365 para ingerir as medições de dispositivos Life365 em Hubs de Eventos.

Outro

Embora as opções acima ajudem a facilitar, essa arquitetura suporta quaisquer fontes de dados semelhantes que possam ser ingeridas com segurança em Hubs de Eventos, direta ou indiretamente por meio de uma API intermediária.

Serviços do Azure (coleta e armazenamento de dados)

  • Hubs de Eventos do Azure - um serviço de ingestão de dados em tempo real totalmente gerenciado que é simples, confiável e escalável. Transmita em fluxo milhões de eventos a partir de qualquer origem, para criar pipelines de dados dinâmicos e responder aos desafios empresariais. Nessa arquitetura, ele é usado para coletar e agregar os dados do dispositivo, para transferência para os Serviços de Dados de Saúde do Azure.

  • Os Serviços de Dados de Saúde do Azure são um conjunto de serviços de API geridos com base em padrões e estruturas abertos que permitem fluxos de trabalho para melhorar os cuidados de saúde e oferecer soluções de cuidados de saúde escaláveis e seguras. Os serviços utilizados nesta arquitetura incluem:

    • Espaço de trabalho dos Serviços de Dados de Saúde do Azure - fornece um contêiner para as outras instâncias dos Serviços de Dados de Saúde do Azure, criando um limite de conformidade (HIPAA, HITRUST) no qual as informações de integridade protegidas podem viajar.

    • Serviço FHIR do Azure - facilita o armazenamento e a troca segura de informações de saúde protegidas (PHI) na nuvem. Os dados do dispositivo são transformados em recursos de observação baseados em FHIR para dar suporte ao monitoramento remoto do paciente.

    • Serviço Azure MedTech - uma pedra angular do Microsoft Cloud for Healthcare, usado para dar suporte ao monitoramento remoto de pacientes. A MedTech é uma plataforma como serviço (PaaS) que permite coletar dados quase em tempo real de diversos dispositivos médicos e convertê-los em um formato de serviço compatível com FHIR e armazená-los em um serviço FHIR. Os recursos de tradução de dados de dispositivos do serviço MedTech tornam possível transformar uma ampla variedade de dados em um formato FHIR unificado que fornece gerenciamento seguro de dados de saúde em um ambiente de nuvem.

      O serviço MedTech é importante para o monitoramento remoto de pacientes porque os dados de saúde podem ser difíceis de acessar ou analisar quando vêm de dispositivos, sistemas ou formatos diversos ou incompatíveis. Informações médicas que não são fáceis de acessar podem ser uma barreira para obter insights clínicos e o plano de saúde de um paciente. A capacidade de traduzir dados de saúde em um formato FHIR unificado permite que o serviço MedTech vincule com sucesso dispositivos, dados de saúde, laboratórios e atendimento remoto presencial. Como resultado, essa capacidade pode facilitar a descoberta de insights clínicos importantes e a captura de tendências, apoiando o clínico, a equipe de cuidados, o paciente e a família. Também pode ajudar a estabelecer ligações a novas aplicações de dispositivos e permitir projetos de investigação avançada. Assim como os planos de cuidados podem ser individualizados por caso de uso, os cenários de monitoramento remoto de pacientes e casos de uso podem variar de acordo com a necessidade individualizada.

  • Grade de Eventos do Azure - o serviço de eventos dos Serviços de Dados de Saúde do Azure gera eventos sempre que um recurso FHIR é criado, atualizado ou excluído (CUD). Esses eventos podem ser transmitidos pela Grade de Eventos do Azure para consumidores downstream para agir em dados baseados em eventos.

Serviços e ferramentas do Azure (análise de dados)

  • FHIR Analytics Pipelines - um projeto OSS usado para criar componentes e pipelines para retangularizar e mover dados FHIR, dos servidores FHIR do Azure para o Azure Data Lake. Nessa arquitetura, os dados são convertidos para JavaScript Object Notation (JSON) e formato Parquet , tornando-os disponíveis para análise com vários serviços de dados do Azure.

  • Ferramentas para Anonimização de Dados de Saúde - um projeto OSS apoiado pela equipe da Microsoft Healthcare ajuda a anonimizar dados de saúde, no local ou na nuvem, para uso secundário, como pesquisa, saúde pública e muito mais. O mecanismo principal de anonimização usa um arquivo de configuração para especificar diferentes parâmetros, bem como métodos de anonimização para diferentes elementos de dados e tipos de dados.

  • Azure Synapse Analytics - um serviço de análise ilimitado que reúne integração de dados, armazenamento de dados corporativos e análise de big data. Dá-lhe a liberdade de consultar dados conforme entender, mediante a utilização de opções dedicadas ou sem servidor, em escala. O Azure Synapse alia estes universos a uma experiência unificada para ingerir, explorar, preparar, transformar, gerir e fornecer dados a necessidades imediatas de BI e machine learning.

  • Apache Spark pools - O Apache Spark é uma estrutura de processamento paralelo que suporta processamento na memória para aumentar o desempenho de aplicativos analíticos de big data. O Apache Spark no Azure Synapse Analytics é uma das implementações da Microsoft do Apache Spark na cloud. O Azure Synapse facilita a criação e configuração de um conjunto do Apache Spark sem servidor no Azure. Os conjuntos do Spark no Azure Synapse são compatíveis com o Armazenamento do Azure e o Armazenamento do Azure Data Lake Generation 2. Por isso, pode utilizá-los para processar os dados armazenados no Azure.

  • Azure Databricks - uma plataforma de análise de dados otimizada para a plataforma de serviços de nuvem do Microsoft Azure. O Databricks fornece uma plataforma de análise unificada para analistas de dados, engenheiros de dados, cientistas de dados e engenheiros de aprendizado de máquina. Três ambientes são oferecidos para o desenvolvimento de aplicativos com uso intensivo de dados: Databricks SQL, Databricks Data Science & Engineering e Databricks Machine Learning.

  • Azure ML - um serviço de nuvem do Azure para acelerar e gerenciar o ciclo de vida do projeto de aprendizado de máquina. Profissionais de aprendizado de máquina, cientistas de dados e engenheiros podem usá-lo em seus fluxos de trabalho diários: treinar e implantar modelos e gerenciar MLOps. Você pode criar um modelo no Azure Machine Learning ou usar um modelo criado a partir de uma plataforma de código aberto, como Pytorch, TensorFlow ou scikit-learn. As ferramentas MLOps ajudam a monitorar, treinar novamente e reimplantar modelos.

  • Power BI - fornece análises de autoatendimento em escala empresarial, permitindo que você:

    • Crie uma cultura orientada por dados com business intelligence para todos.
    • Mantenha seus dados seguros com recursos de segurança de dados líderes do setor, incluindo rotulagem de sensibilidade, criptografia de ponta a ponta e acesso em tempo real monitoring.is usados para análise adicional de dados FHIR.

  • Os conectores do Power Query usados com o Power BI incluem:

  • SQL Server Management Studio - um aplicativo de área de trabalho usado para criar consultas SQL nativas em armazenamentos de dados SQL, como pools SQL do Azure Synapse Analytics.

Alternativas

Life365.saúde

A vantagem do Life365.health é que, com um ponto de integração, você pode enviar medições de uma ampla gama de dispositivos no ecossistema Life365 para os Serviços de Dados de Saúde do Azure. Existem outras APIs de dispositivos vestíveis, como a Garmin Activity API e a Polar AccessLink API, para as quais um padrão de integração semelhante pode ser alcançado. No entanto, essas APIs são exclusivas para medição de dispositivos de seus próprios fabricantes, como Garmin e Polar, respectivamente.

Dispositivos e pacientes precisam ser definidos, vinculados e sincronizados entre os Serviços de Dados de Saúde do Azure e a API Life365. Essa configuração pode ser obtida sincronizando as IDs do paciente e do dispositivo entre os Serviços de Dados de Saúde do Azure e a API Life365. Em essência, um novo paciente e dispositivo é criado e vinculado no Serviço FHIR do Azure primeiro. Em seguida, o paciente e o dispositivo correspondentes são criados e vinculados na API Life365. As IDs dos pacientes e dispositivos, criadas pela primeira vez nos Serviços de Dados de Saúde do Azure, serão atualizadas como IDs externas nas respetivas entidades de pacientes e dispositivos na API do Life365.

Microsoft Cloud para HealthCare

Este exemplo de carga de trabalho aborda uma maneira de implementar uma solução de monitoramento remoto de pacientes. O Microsoft Cloud for Healthcare também fornece uma solução de monitoramento remoto de pacientes. Para obter mais informações sobre essa solução, consulte a visita guiada de monitoramento remoto de pacientes.

Detalhes do cenário

Há uma abundância de dispositivos médicos e vestíveis/de consumo por aí hoje. Para acessar medições/leituras de dispositivos, muitos dos dispositivos de monitoramento em casa (como dispositivos de pressão arterial, escala... etc.) fornecer conectividade Bluetooth (como Bluetooth Low Energy ou outras versões mais antigas do padrão Bluetooth). Há também dispositivos vestíveis de consumo, bem como dispositivos domésticos mais avançados que fornecem conectividade API para acessar as medições dos dispositivos. Neste caso, os dispositivos podem sincronizar as leituras diretamente com a API (Wi-Fi habilitado) ou se conectar a um aplicativo móvel em um smartphone (via Bluetooth), permitindo que o aplicativo sincronize a leitura de volta à API.

Declaração do problema

Dada a ampla gama de dispositivos médicos vestíveis e domésticos e opções de conectividade (de Bluetooth a especificação de API), multiplicada pelo número de pacientes dentro da organização de saúde, a integração e orquestração de dados pode se tornar uma tarefa assustadora.

Potenciais casos de utilização

  • Ensaios clínicos e investigação – Ajude as equipas de investigação clínica a integrar e oferecer uma vasta gama de dispositivos médicos domésticos e vestíveis ao participante no estudo. Em outras palavras, ofereça uma opção de quase traga seu próprio dispositivo (BYOD) aos participantes do estudo.

  • Ciência de dados e análise de saúde populacional – Os dados de atividade e fisiológicos estarão disponíveis no formato padrão FHIR da indústria, bem como outros formatos de dados de código aberto (JSON e Parquet). Além do formato de dados, conectores nativos são fornecidos para ajudar na análise e transformação de dados. Incluindo conectores como o conector do Power BI para FHIR, exibições SQL sem servidor Synapse e clusters Spark no Synapse.

    Esta solução também fornece um método parametrizado para anonimizar o conjunto de dados para fins de pesquisa não identificados. Esses "dados de uso secundário" podem ser analisados e usados para encontrar as melhores práticas e dar suporte a fluxos de trabalho baseados em evidências clínicas. As observações armazenadas no servidor FHIR podem ser usadas para encontrar variações e fluxos de trabalho que promovem os melhores resultados e práticas.

  • Habilitar prestadores de cuidados de saúde - Os prestadores poderão:

    • obter melhores informações sobre o estado de saúde do paciente
    • criar modelos de cuidados de saúde digitais proativos para cuidados médicos preventivos
    • tomar medidas mais informadas com base nos indicadores/notificações fisiológicas
    • fornecer vias para o reembolso do monitoramento fisiológico remoto

  • Questionários de Resultado Relatado pelo Paciente (PRO) e cuidados orientados por PRO - Usando eventos e questionários PRO, planos de cuidados individualizados e fluxos de trabalho de variância de cuidados podem ser criados. O paciente pode ter mais autonomia e controle sobre o plano de cuidados individualizado, o que ajuda na adoção e no uso sustentado. Os cuidados orientados para a PRO também podem ser úteis para resolver a lacuna na educação e nos resultados dos pacientes. Ao vincular questionários educacionais e PROs, o RPM pode ser usado para apoiar a medicação, o tratamento e/ou os cuidados de acompanhamento, respondendo a perguntas como:

    • Os pacientes estão tomando a PA corretamente?
    • A escala está a ser utilizada no momento e na frequência certos?
    • Estamos fazendo looping em PROs para adoção de pacientes e planejamento de cuidados individualizados?

    Para pacientes que usam dispositivos iOS, os aplicativos de questionário podem ser criados usando o Apple ResearchKit. Os dados do questionário são ingeridos pelos Hubs de Eventos do Azure e disponibilizados por meio do serviço FHIR, assim como a atividade do paciente do dispositivo e os dados fisiológicos.

  • Permitir vários tipos e dispositivos de saúde mais precisos - Use dispositivos médicos e domésticos para gerar dados de saúde quase em tempo real para ingestão e análise de dados.

Considerações

Essas considerações abordam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.

A disponibilidade de dados clínicos e insights é fundamental para muitas organizações de saúde. Eis algumas formas de minimizar o tempo de inatividade dos serviços do Azure indicados nesta solução:

  • O armazenamento Data Lake é sempre replicado três vezes na região principal, com a opção de escolher LRS (armazenamento com redundância local) ou ZRS (armazenamento com redundância de zona).

  • Os Hubs de Eventos do Azure espalham o risco de falhas catastróficas de máquinas individuais ou até mesmo racks completos entre clusters que abrangem vários domínios de falha em um datacenter. Para obter mais informações, consulte Hubs de Eventos do Azure - Recuperação de desastres geográficos.

  • A Databricks fornece orientação de recuperação de desastres para sua plataforma de análise de dados.

  • A implantação do Machine Learning pode ser multirregional.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Os dados de cuidados de saúde incluem frequentemente informações de saúde protegidas (PHI) sensíveis e informações pessoais. Os seguintes recursos estão disponíveis para proteger esses dados:

  • O Armazenamento Data Lake usa o RBAC (controle de acesso baseado em função) e as ACLs (listas de controle de acesso) do Azure para criar um modelo de controle de acesso

  • Os Serviços de Dados de Saúde do Azure são uma coleção de serviços geridos seguros que utilizam o Microsoft Entra ID, um fornecedor de identidade global que suporta OAuth 2.0. Quando cria um novo serviço dos Serviços de Dados de Saúde do Azure, os dados são encriptados com as chaves geridas pela Microsoft por predefinição. Consulte Autenticação e Autorização para Serviços de Dados de Saúde do Azure para obter mais detalhes.

  • Os Hubs de Eventos do Azure fornecem criptografia de dados em repouso com a Criptografia do Serviço de Armazenamento do Azure (Azure SSE). Como tal, as regras de Firewall IP podem ser aplicadas no Nível de namespace dos Hubs de Eventos. O acesso a pontos de extremidade privados e rede virtual também pode ser configurado.

  • Synapse RBAC estende os recursos do Azure RBAC para espaços de trabalho Synapse e seu conteúdo. O RBAC do Azure é usado para gerenciar quem pode criar, atualizar ou excluir o espaço de trabalho Synapse e seus pools SQL, pools Apache Spark e tempos de execução de integração.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Os preços de muitos dos componentes do Azure podem ser encontrados na Calculadora de Preços do Azure. Em última análise, o preço desta solução é baseado em fatores como:

  • Os serviços do Azure que são usados.
  • Volume de dados, em termos do número de doentes/dispositivos e do número de atividade e tipos de dados fisiológicos ingeridos.
  • Requisitos de capacidade e taxa de transferência para Hubs de Eventos.
  • Recursos de computação necessários para executar treinamentos e implantações de aprendizado de máquina, Synapse Spark Pools e clusters Databricks.
  • A solução de visualização e relatórios, como o Power BI.

Ao implementar esta solução, considere a política de retenção e arquivamento de dados para o Azure Data Lake subjacente. Aproveite o gerenciamento do ciclo de vida do Armazenamento do Azure para fornecer uma maneira automatizada de:

  • O arquivo de transição é blobs para a camada de acesso legal
  • Camadas de arquivamento com base em quando o arquivo foi modificado pela última vez.

Para saber mais sobre os planos e preços Life365.health, consulte a oferta Life365 API Connect Data no Microsoft Azure Marketplace

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

Esta solução fornece uma arquitetura escalável quase em tempo real para monitoramento remoto de pacientes. É importante reconhecer o fluxo de dados em várias camadas da interface entre os dispositivos e a API Life365, a ingestão da API Life365 e dos Hubs de Eventos do Azure, a transformação no Serviço MedTech no Serviço de Dados de Saúde do Azure e, por último, a exportação incremental e a anonimização para o formato data lake. Assim, o fluxo de dados será processado quase em tempo real e qualquer aplicação a jusante e/ou integrações devem ser concebidas como tal. No entanto, o desempenho desta solução pode ser dimensionado para servir um grande número de dispositivos e pacientes a nível empresarial.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Tecnologias e recursos relevantes para a implementação desta arquitetura: