Consulta médica virtual no Microsoft Cloud for Healthcare

Azure

Este artigo aborda uma possível solução para agendar e acompanhar as consultas virtuais entre pacientes, provedores e gerentes de atendimento.

Arquitetura

Architecture for virtual visit using Microsoft Cloud for Healthcare

Baixe o arquivo Visio que contém esse diagrama de arquitetura.

Neste diagrama de arquitetura, as caixas de linha azul representam o serviços Microsoft que são os serviços subjacentes ou complementos necessários para o Microsoft Cloud for Healthcare. Cada um deles precisa ser licenciado separadamente. Esses componentes juntos ajudam a acelerar o desenvolvimento de soluções de serviços de saúde integradas para participação de pacientes, colaboração da equipe de saúde e aprimoramento de insights de dados clínicos e operacionais.

Os dados fluem para o sistema por meio de vários sistemas médicos externos, como agendamentos de pacientes e provedores, registros médicos, dispositivos portáteis e assim por diante. Esses dados são ingeridos com o Azure. Em seguida, eles são armazenados no Microsoft Dataverse, um armazenamento de dados da plataforma Power Apps. Esses dados são formatados para usar entidades e relações entre elas, criados com o CDM (Common Data Model), um padrão do setor para representar dados médicos. Todas as interações entre o paciente, o provedor e o gerente de atendimento ocorrem usando esses dados do CDM armazenados no Dataverse.

Um paciente estabelecido pode fazer login com segurança no Portal do Paciente, um site hospedado nos portais do Power Apps. Nesse portal, o paciente pode se falar com um Assistente Inteligente. Essa é uma instância do serviço Azure Health Bot, que reúne sintomas, oferece sugestões e recomenda ligar para o profissional, se necessário. Se o paciente optar por se conectar ao provedor médico, a instância do bot de saúde obtém os dados nos provedores disponíveis para consultas virtuais e suas agendas, do Dataverse. Depois que o paciente escolhe um provedor e um horário, o bot apresenta as informações de contato, obtidas dos dados EMR/EHR armazenados no Dataverse. O paciente pode validar ou mudar essas informações e salvar os dados usando o bot.

Para fazer o agendamento, a instância do Health Bot se conecta ao aplicativo Bookings usando a API do Microsoft Graph e agenda um compromisso no calendário do provedor. Um email com as informações de compromisso é enviado a ambas as partes usando o Microsoft Outlook. O paciente recebe instruções para fazer login no Portal do Paciente para o processo de ingestão. Esse processo envolve confirmar ou alterar as informações de contato, pagamento e seguro e, em seguida, assinar um formulário de consentimento para a consulta virtual. Depois que ele assina o consentimento, será enviado um link do Microsoft Teams para o compromisso.

O provedor entra no Teams para verificar a agenda de compromissos e as informações de resumo de cada um. O Teams apresenta essas informações com o aplicativo Fila de compromissos. O provedor pode iniciar a consulta virtual no Teams para o compromisso agendado. Durante a chamada, o provedor pode fazer anotações e adicioná-las aos registros do paciente.

Uma nova observação sobre os registros médicos do paciente dispara uma notificação de revisão para o gerente de atendimento atribuído ao paciente. Quando o gerente de atendimento recebe essa notificação, ele pode fazer log in no Teams, onde pode ver os pacientes atribuídos a ele e exibir as observações. Por meio do aplicativo Gerenciamento de Assistência Médica, ele pode fazer mudanças necessárias no plano de atendimento do paciente.

Componentes

Essa arquitetura consiste nos seguintes componentes:

  • PAS. Os Sistemas de administração de pacientes (PAS) são sistemas que automatizam a documentação administrativa em organizações de saúde, como hospitais. Eles são os principais componentes da infraestrutura de TI de uma organização desse tipo. Um PAS registra os dados demográficos do paciente, como nome, endereço residencial, data de nascimento e assim por diante. Ele também registra informações detalhadas de todos os contatos que o paciente teve com o hospital, tanto internado quanto em tratamento fora dele. Com a ajuda do PAS, hospitais modernos são capazes de relatar e agendar recursos em toda a organização. O PAS é uma fonte chave de agendamento de dados nesta solução. Como esses dados são externos e podem estar em um formato não padrão, é importante convertê-los em um formato que seja compreendido por todos os componentes dessa solução.

  • EMR/EHR. Os Registros Médicos Eletrônicos (EMR) e os Registros Eletrônicos de Saúde (EHR) oferecem os registros digitais das informações médicas e de saúde de um paciente, incluindo diagnósticos, exames, imunizações, etc. O escopo deles pode ser um único consultório, como EMRs, ou um escopo muito maior, viajando com os pacientes para qualquer instalação que eles vão, como os EHRs. Eles são fontes de dados externas importantes nessa solução e podem ter formato não padrão não estruturado. Dessa forma, esses dados precisam ser convertidos em um formato que possa ser usado pelos componentes nesta solução.

  • API do Azure para FHIR. O Azure é a primeira etapa no processo de trazer dados para o ecossistema da Microsoft e o Microsoft Cloud for Healthcare. Essa camada oferece uma interface segura entre dados externos e componentes internos dessa arquitetura. O API do Azure para FHIR ingere os dados provenientes de fontes diferentes, como EMR, PAS, dispositivos, seja estruturados ou não, converte-os em FHIR e persiste no Azure. Esses dados podem ser usados no Microsoft Cloud for Healthcare para serviços diferentes. A API do Azure para FHIR é criada pensando na segurança e conformidade e projetada para dados de PHI (Informações Protegidas de Saúde). Para obter mais informações sobre essa camada, consulte Azure nos serviços de saúde e API do Azure para FHIR

  • Common Data Model. Com o Common Data Model, a Microsoft oferece um sistema de definição de metadados padronizado, que pode ser estendido e personalizado para necessidades comerciais específicas. As entidades do CDM estão disponíveis para áreas de assunto, como CRM, Saúde, Talento e assim por diante. Para obter detalhes, leia as informações de uso do Common Data Model. Além dessas entidades, os clientes podem efetuar pull de dados proprietários definindo essa tabela de entidade e os campos subjacentes no Common Data Model, que podem ser usados com outras entidades em toda a solução.

  • Microsoft Dataverse. O Dataverse, um banco de dados relacional que alimenta o Microsoft Dynamics 365, é o repositório dos dados representados no Common Data Model. Ele mantém bancos de dados para informações de pacientes, contém detalhes sobre seus nomes, informações de família, condições médicas, histórico de pacientes e assim por diante. Ele também contém as informações obtidas de todos os dispositivos vestíveis e registrados pelos pacientes, bem como os dados de agendamento e gerenciamento da organização de serviços de saúde. Esses dados são definidos usando o Common Data Model.

  • Portal do paciente. Esse portal do Power Apps permite que os pacientes vejam seus registros médicos, agendem consultas, conversem com a instância do bot de saúde e assim por diante. Esse portal pode ser estendido para permitir outros dados. Esse portal faz parte do Microsoft Cloud for Healthcare e permite criar facilmente um portal, que pode se conectar com entidades no Dataverse, efetuar pull de dados como informações do paciente, planos de atendimento, consultas e assim por diante.

  • Assistência inteligente. Essa é uma instância do Serviço do Azure Health Bot, acessível aos pacientes por meio do Portal do Paciente. Essa instância do Health Bot é carregada em um site do Serviço de Aplicativo do Azure. Ele é personalizável e pode ser programado usando os cenários exigidos pelos clientes.

  • Aplicativo Bookings. O aplicativo Bookings é um serviço do Microsoft 365, incluído no Microsoft Cloud for Healthcare. Ele facilita o agendamento de eventos de calendário e permite a criação de reuniões do Teams.

  • Microsoft Outlook. Essa solução usa o Microsoft Outlook como o cliente de email. O aplicativo Bookings que envia a notificação por email é integrado ao Outlook. Como alternativa, o cliente de email preferencial do provedor pode ser usado.

  • Microsoft Teams. O Microsoft Teams é um componente do Microsoft Cloud for Healthcare e oferece o front-end para interações entre os pacientes, provedores e gerentes de atendimento. Os usuários podem usar uma versão instalada localmente ou a versão da Web. Para obter mais informações sobre o Teams, leia a documentação do Microsoft Teams.

  • Fila de compromisso. Essa ferramenta gera uma página HTML com dados retirados do Dataverse, usando a API Web do Dynamics 365. Ele apresenta ao provedor informações sobre os compromissos agendados para o dia e resumo de cada um. Ele também oferece um link para acessar as informações do paciente por meio do aplicativo Gerenciamento de Assistência Médica. A Fila de Compromissos foi desenvolvida para permitir esse cenário e não faz parte do Microsoft Cloud for Healthcare. As fontes de dados para essa ferramenta são principalmente os sistemas PAS e registros EMR/EHR. Se esses sistemas têm ferramentas integradas para apresentar esses dados, elas podem ser uma substituição para esse componente em uma implantação real.

  • Gerenciamento de Assistência Médica. A ferramenta Gerenciamento de Assistência Médica é um componente do Microsoft Cloud for Healthcare. É um aplicativo Power Apps implantado por meio do Dynamics 365. Ele efetua pull dos dados de pacientes EMR/EHR armazenados no Dataverse no formato CDM e apresenta uma exibição agregada no Teams. A solução de um centro de atendimento pode optar por usar seu próprio sistema para sua funcionalidade, dependendo de como eles querem apresentar essas informações.

  • Power BI Analytics. Essa é uma ferramenta de análise criada para esse cenário e não está disponível com o Microsoft Cloud for Healthcare. Nesta solução, ele gera informações derivadas dos dispositivos IoMT do paciente. Podem ser dados como taxa cardíaca, nível de oxigênio no sangue etc. O aplicativo Gerenciamento de Assistência Médica usa esses dados para apresentar informações adicionais aos provedores médicos sobre seus pacientes com base nas atividades diárias.

  • Dispositivos conectados. São dispositivos de Internet da Coisas Médicas (IoMT), que são dispositivos inteligentes para uso médico ou de assistência médica. Exemplos de dispositivos IoMT incluem dispositivos que podem ser Apple Watch ou Fitbit, monitores médicos ou vitais e assim por diante. Os pacientes podem provisionar dispositivos por meio do Azure e optar por permitir que seu sistema de gerenciamento de serviços de saúde reúna esses dados de IoMT para uso por seus provedores. Os provedores podem obter insights adicionais desses dispositivos, quase em tempo real, e vincular anomalias, como uma taxa de frequência cardíaca elevada por um intervalo de tempo, com os sintomas atuais do paciente.

  • Automação com Power Automate. Essa é uma ferramenta personalizada criada para permitir esse cenário e não está disponível com o Microsoft Cloud for Healthcare. Como esse é um cenário de consulta virtual, o provedor pode ser apenas um paciente de plantão e não um paciente normal. Essa ferramenta permite que as notas do provedor acionem uma notificação do Teams para o gerente de atendimento. Um gerente de atendimento é o membro da equipe médica que atua como o contato entre o médico de atenção primária (PCP) e o paciente, e cuida do gerenciamento de atendimento de longo prazo. Uma notificação enviada ao gerente de atendimento, indicando novas notas adicionadas para o paciente, permite que ele revise e faça as mudanças apropriadas no gerenciamento de atendimento do paciente após a visita.

Alternativas

Os serviços Azure nos serviços de saúde, como API do Azure para FHIR e Azure Health Bot, interface do Common Data Model, Microsoft Dataverse e Microsoft Teams formam os principais componentes dessa solução. A maioria dos outros componentes desse sistema pode ser substituída por sistemas usados atualmente pela instalação de serviços de saúde:

  • Se o sistema EMR/EHR vem com recursos integrados para marcação, agendamento e gerenciamento de atendimento, eles podem ser usados em vez dos componentes correspondentes nessa solução.

  • Os agendamentos do Bookings e Outlook e a notificação por email podem ser trocados pelos sistemas usados na instalação de assistência médica. Isso pode ser feito por meio do sistema EHR ou um aplicativo de terceiros. O aplicativo deve oferecer uma API que a instância do Health Bot pode usar para criar e agendar consultas, com a capacidade de criar reuniões virtuais.

  • Se o provedor já tiver um portal de pacientes implementado por meio de seu sistema EMR/EHR, ele poderá ser usado em vez do Portal do Paciente. É fácil integrar esse componente externo a essa solução, pois esses componentes usavam interfaces padrão, por exemplo, uma interface iFrame para se comunicar com a instância do Health Bot. Os componentes que suportam esse fluxo podem ser criados no portal proprietário, como o formulário de consentimento que o paciente precisa assinar antes de ingressar na reunião do Teams.

  • Vale a pena notar que uma implantação real precisará de ferramentas de substituição para alguns componentes dessa solução, como a Fila de Compromissos, notificações automatizadas e ferramentas de análise Power BI. Esses componentes precisarão ser criados e personalizados para as necessidades de negócios do provedor de serviços de saúde.

Detalhes do cenário

Na pandemia atual de COVID-19 (coronavírus), um grande número de pacientes pode preferir fazer consultas médicas virtuais em vez de presenciais, sempre que possível. Melhorar insights clínicos e operacionais em serviços de saúde torna-se importante nesse mundo virtual. Isso inclui conexão de dados entre sistemas, criação de insights para prever riscos e ajudar a melhorar o atendimento aos pacientes, garantia de qualidade e eficiências operacionais.

A base para essa solução é o Microsoft Cloud for Healthcare. O Microsoft Cloud for Healthcare reúne recursos confiáveis do Microsoft 365, do Azure, do Dynamics 365, do Power Platform e do amplo ecossistema de parceiros da Microsoft para ajudar as organizações de saúde a criar soluções de serviços de saúde rápidas, eficientes e seguras.

Possíveis casos de uso

Essa solução tem o objetivo oferecer assistência virtual ao paciente na pandemia atual. No entanto, os provedores de serviços de saúde podem aplicá-la facilmente aos seguintes cenários:

  • Agendar acompanhamentos virtuais a consultas presenciais.

  • Oferecer diretrizes médicas não emergenciais aos pacientes durante viagem.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Como o sistema é criado em torno de dados de pacientes, as considerações básicas de segurança para informações privadas devem ser aplicadas ao desenvolver esta solução:

  • Somente os dados necessários devem fluir pelo sistema a qualquer dado momento. Por exemplo, efetue pull apenas dos dados dos sistemas EMR/EHR necessários para o agendamento e o gerenciamento de visita virtual. Revise as regras de conformidade do HIPAA estabelecidas para obter diretrizes sobre onde os dados do paciente devem ser armazenados, o que pode ser feito com eles e quem deve ter acesso a eles. Esteja ciente da importância da conformidade em serviços de saúde ao desenvolver sua solução. Para obter mais diretrizes, leia Conformidade no Microsoft Cloud for Healthcare.

  • Somente os funcionários autorizados devem ter acesso aos dados do paciente e somente aos dados necessários para sua função. Em vários pontos do sistema, como o Gerenciamento de Atendimento e as análises que aproveitam seus dados, a Fila de Compromissos ou os sistemas de notificação, é necessário ter cuidado para autenticar e autorizar a equipe e limitar o acesso a apenas as informações de pacientes necessárias.

  • Módulos que interagem com pacientes, como o aplicativo Intelligent Assistance e Bookings, recebem, armazenam e usam dados de pacientes. O controle de acesso e a autenticação adequados nesses módulos garantem que as preocupações de privacidade sejam resolvidas.

Devido à natureza dos dados privados envolvidos, a segurança e a conformidade formam os princípios básicos do Microsoft Cloud for Healthcare.

Este exemplo também se baseia nas regras de segurança definidas pelo Dynamics 365 e pelo Teams:

Os serviços individuais incluídos no Microsoft Cloud for Healthcare oferecem a própria camada de segurança e conformidade:

Para controles de segurança personalizados, considere usar o Microsoft Entra ID e o controle de acesso baseado em função.

Por fim, ao implementar essa solução, tenha em mente as melhores práticas e diretrizes para o desenvolvimento de soluções seguras do Azure.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Para obter informações detalhadas sobre preços do Microsoft Cloud for Healthcare, consulte Como comprar o Microsoft Cloud for Healthcare. Os componentes que formam o Microsoft Cloud for Healthcare têm seus próprios requisitos de licenciamento, como:

Para recriar componentes nessa arquitetura que foram personalizados, considere as informações de preços dos serviços subjacentes que você opta por usar.

Implantar este cenário

A solução deve ser implantada em estágios:

  1. Alguns produtos/serviços precisam ser instalados como os pré-requisitos para Microsoft Cloud for Healthcare. Consulte a lista detalhada neste artigo sobre requisitos de licenciamento.

  2. O Microsoft Cloud for Healthcare pode ser implantado usando as instruções oferecidas nas Soluções do Microsoft Cloud for Healthcare da plataforma Dynamics 365.

  3. O Microsoft Cloud for Healthcare oferece componentes básicos para começar a criar uma solução de saúde virtual, como o Portal do Paciente, Teams, Bookings e assim por diante. Os dados que serão usados para capacitar esses componentes devem ser personalizados de acordo com as necessidades de negócios.

  4. Os componentes disponíveis no Microsoft Cloud for Healthcare e seus pré-requisitos devem ser personalizados para atender às necessidades de negócios:

    1. Os fluxos do Power Automate devem ser criados para permitir notificações do gerenciador de atendimento.

    2. O Portal do Paciente deve ser configurado. Formulários adicionais podem precisar ser criados para elementos como os formulários de check-in/consentimento. Leia Instalar e configurar um portal de Acesso do Paciente para obter mais informações.

    3. O serviço Azure Health Bot deve ser conectado ao banco de dados do Dataverse e personalizado para sua comunicação com pacientes. Leia Configurar chats automáticos com o Microsoft Health Bot para obter mais informações.

    4. Confira Configurar a sincronização com dados clínicos usando o Agente de Sincronização do Azure FHIR e Integrar relatórios Power BI para análise para entender algumas outras configurações que podem ser necessárias.

  5. Os componentes adicionais que foram criados especificamente para essa solução não estão disponíveis para uso de nível de produção. A instalação de serviços de saúde pode precisar criar a própria versão desses aplicativos:

    1. Fila de compromissos

    2. Notificações automatizadas usando o Power Automate

    3. Aplicativo de relatório usando o Power BI

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

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

Próximas etapas