Dataverse Healthcare APIs: usar um modelo de pipeline de dados de saúde para implantar Aplicativos Lógicos do Azure
Este artigo fornece um guia passo a passo para usar um modelo para implantar um grupo de Aplicativos Lógicos do Azure que ingerem dados de FHIR nas Dataverse Healthcare APIs, nos Serviços de Dados de Saúde do Azure ou em ambos. Esta solução funciona como um fluxo de Aplicativo Lógico pronto para empresas que serve como retransmissão entre os Serviços de Dados de Saúde do Azure e as Dataverse Healthcare APIs. O fluxo também gerencia a lógica de repetição e o tratamento de exceções. Ele depende de um gatilho do Armazenamento de Blobs do Azure, em vez do gatilho HTTP usado na configuração manual.
Esse fluxo de trabalho está disponível para implantação como um modelo do ARM (Gerenciador de Recursos de Azure) chamado Modelo de pipeline de dados dos serviços de saúde. Você pode implantar o modelo no Centro de Soluções do Microsoft Cloud. Esta oferta é uma solução mais robusta e com suporte oferecida pelo Microsoft Cloud for Healthcare. Você deverá definir algumas configurações manuais básicas depois que implantar o modelo.
Observação
Este fluxo de Aplicativo Lógico é fornecido como um ponto de entrada para dados de EHR (Registros Eletrônicos de Saúde) de entrada, garantindo que os dados de FHIR sejam postados nos serviços corretos. Ele não é uma solução final em seu estado atual e destina-se a ser atualizado com base em suas necessidades de negócios.
Esses serviços de aplicativo lógico não são necessários para postar dados de FHIR nos ponto de extremidade da Dataverse Healthcare API. Você pode optar por criar sua própria solução para retransmitir dados de seu EHR para as APIs e manipular as respostas.
Os serviços de aplicativo lógico dependem de um gatilho do Armazenamento de Blobs do Azure para desencadear o processamento assíncrono dos pacotes postados em um local de armazenamento configurável. Essa opção lida com cargas mais pesadas para casos de uso corporativos e inclui etapas extras de tratamento de exceções. No entanto, você deve realizar testes completos com suas cargas diárias esperadas.
Após a implantação, você poderá estender o Aplicativos Lógicos para atender às necessidades específicas do seu sistema.
Importante
Este modelo do ARM é compatível somente com o ciclo de lançamentos 2 de 2022 do Microsoft Cloud for Healthcare e versões posteriores. Para versões mais antigas, exclua a ação Definir requestBody como resposta FHIR em caso de êxito antes de desencadear uma execução.
A configuração inclui as seguintes etapas:
- Pré-requisitos
- Projetar
- Etapas de pós-implantação
- Gerenciar erros
- Configurar repetições
- Proteger Aplicativos Lógicos
Pré-requisitos
Certifique-se de que seu ambiente atenda aos seguintes requisitos antes de implantar o modelo:
- Uma conta e assinatura do Azure. Se você não tiver uma assinatura, inscreva-se para receber uma conta gratuita do Azure antes de começar.
- Um grupo de recursos do Azure configurado com permissões apropriadas para criar recursos ou uma função de Colaborador para criar grupos de recursos.
- Acesso dentro do grupo de recursos para criar recursos e atribuir funções do Azure.
- Aderência às diretrizes de segurança descritas pelos administradores do Azure e política da organização.
Projetar
O diagrama a seguir ilustra o design do pipeline implantado por meio do modelo:
O modelo do ARM implanta vários Aplicativos Lógicos modularizados. Ele inclui os três serviços de aplicativo lógico a seguir:
| Aplicativo Lógico | Descrição |
|---|---|
| Processar pacote FHIR | A primeira instância de aplicativo lógico desencadeada quando um pacote é carregado no armazenamento de blobs. Esse aplicativo lógico determina se o pacote deve ser postado no FHIR ou diretamente no Dataverse. |
| Enviar pacote para o FHIR | O segundo aplicativo lógico desencadeado a partir do aplicativo lógico Processar Pacote FHIR, quando você opta por postar o pacote no FHIR. Esse aplicativo lógico processa o pacote de solicitação e o envia para o servidor FHIR. Depois que esse aplicativo lógico posta o pacote no servidor FHIR, ele retransmite o pacote para o próximo aplicativo lógico Enviar Pacote para o Dataverse para processamento adicional. |
| Enviar pacote para o Dataverse | O aplicativo lógico final é desencadeado pelo aplicativo lógico Processar pacote FHIR ou Enviar pacote para o FHIR. Ele processa o pacote de solicitação e publica o pacote no Dataverse. Ele também lida com a limpeza do contêiner de pacotes, movendo o pacote de solicitação para o contêiner bundleserror ou bundlesarchive. |
Parâmetros do modelo
| Parâmetro | Descrição |
|---|---|
| Local do recurso | A região do Azure para a criação do recurso. Esse valor de parâmetro tem como padrão a região usada para criar o grupo de recursos. |
| URL do Dataverse | A URL do seu ambiente do Dataverse no Microsoft Cloud for Healthcare. Por exemplo, https://*orgname*.crm.dynamics.com |
| Publicar no servidor FHIR | Um valor booliano. Se definido como verdadeiro, o pacote será postado no servidor FHIR. |
| URL do servidor FHIR | A URL do seu servidor FHIR. Por exemplo, https://*fhirserver*.azurewebsites.netvocê só precisa desse parâmetro se quiser postar no servidor FHIR antes de postar no ponto de extremidade de API upsert do Dataverse. |
| Valor exclusivo | A cadeia de caracteres exclusiva usada para gerar nomes de recursos. Esse valor é padronizado para a função uniqueString. É possível substituir esse valor se necessário. |
Recursos implantados
O modelo implanta os seguintes recursos em seu ambiente:
| Recurso | Descrição |
|---|---|
| Identidade gerenciada | O nome da identidade gerenciada tem o formato mi_UniqueValue. Essa identidade gerenciada é atribuída ao aplicativo lógico e recebe acesso à conta de armazenamento, ao servidor FHIR e ao ambiente do Dataverse. |
| Conta de armazenamento do Azure | O nome da conta de armazenamento tem o formato sa_UniqueValue. Juntamente com a conta de armazenamento, o modelo também implanta os três contêineres a seguir: bundles, bundlesarchive e bundleserror. |
| Atribuição de função | Atribui a função Colaborador de dados do blob de armazenamento na conta de armazenamento à identidade gerenciada. |
| Grade de Eventos do Azure | O nome da Grade de Eventos tem o formato eg_UniqueValue. Todos os eventos do blob são postados nessa Grade de Eventos. |
| Barramento de Serviço do Azure | O nome do Barramento de Serviço tem o formato sb_UniqueValue. A Grade de Eventos posta eventos nesse Barramento de Serviço. O nome da fila é bundleCreated. |
| Regra de autorização | Cria uma regra de autorização Escutar no Barramento de Serviço com o nome bundleauthlisten. |
| Aplicativo Lógico do Azure | Um conjunto de fluxos de trabalho relacionados do aplicativo lógico do tipo Consumo. O fluxo de trabalho desencadeia os eventos do Barramento de Serviço. Esses aplicativos lógicos processam o pacote FHIR de entrada e o posta nos pontos de extremidade configurados. Cada aplicativo lógico é nomeado usando o valor exclusivo fornecido durante a implantação: 1. laprocessfhirbundle_UniqueValue 2. lasendbundletodataverse_UniqueValue 3. lasendbundletofhir_UniqueValue |
| Conexão de API | Várias conexões de API necessárias para os aplicativos lógicos. |
Saída
Dependendo se a execução termina com êxito ou falha, um blob com o nome originalblobname_response.json é criado na pasta bundlesarchive ou bundleserror com o seguinte esquema:
{
"dataverseResponse": "<The response from the Dataverse healthcare API post the call.>",
"fhirServerResponse": "<The response from the FHIR server call if the "Post to FHIR server" parameter value was set to True.>",
"statusMessage": "<Summary of the responses. In case of a failure, the message provides details about how many resources failed to post to the FHIR server and to Dataverse.>",
"statusCode": "<Code value associated with the issue encountered.>"
}
Dependendo de qual aplicativo lógico tiver desencadeado o erro, o erro JSON conterá o nó dataverseResponse ou fhirServerResponse . Por exemplo, se você encontrar um erro com o aplicativo lógico lasendbundletofhir_UniqueValue, resposta JSON conterá somente o nó fhirServerResponse e o valor.
Etapas de pós-implantação
A seção a seguir contém as etapas que você deve seguir após a implantação do modelo.
Conceder acesso ao servidor FHIR
Acessar o servidor FHIR do aplicativo lógico requer a atribuição de função Colaborador de dados de FHIR, que permite publicar novos dados no serviço. Adicione essa atribuição de função do Azure à identidade gerenciada usada pelo aplicativo lógico.
Vá para a instância do servidor FHIR, selecione Controle de Acesso (IAM) e, em seguida, selecione Adicionar atribuição de função.
Na guia Função, selecione a função Colaborador de dados de FHIR.
Selecione Membros, Identidade Gerenciada e depois + Selecionar membros.
Adicione a identidade gerenciada criada com a implantação do modelo do ARM. A identidade gerenciada recém-implantada deve ser nomeada mi_UniqueValue.
A atribuição pode levar alguns minutos para refletir na identidade gerenciada. Selecione Atribuições de função do Azure para exibir a atribuição de função na identidade gerenciada.
Conceder acesso às Dataverse Healthcare APIs
A mesma identidade gerenciada é usada no aplicativo lógico para acessar as Dataverse Healthcare APIs conectando-o a um usuário de aplicação no destino da instância do Dataverse. Para obter mais informações sobre os usuários do aplicativo, acesse Gerenciar usuários de aplicativos no centro de administração da Power Platform.
Você precisa da ID de cliente do Azure para a identidade gerenciada para configurar o usuário do aplicativo. Para recuperar a ID do Cliente, abra a identidade gerenciada criada com a implantação do modelo do ARM e copie o valor da ID do Cliente da área Visão geral.
No Centro de Administração da Power Platform, abra o ambiente Microsoft Cloud for Healthcare de destino. Na seção Acesso, selecione Aplicativos S2S e, em seguida, selecione Novo usuário do aplicativo.
No painel Criar um usuário do aplicativo, selecione a Unidade de negócios apropriada e selecione Adicionar um aplicativo.
No painel Adicionar um aplicativo a partir do Microsoft Entra ID, procure o ID do Cliente que você copiou da identidade gerenciada.
Selecione a identidade gerenciada na lista, selecione Adicionar e edite os direitos de acesso.
Selecione o direito Usuário de Registro do Aplicativo de Administração de Sincronização FHIR e selecione Salvar.
Selecione Criar para criar o novo usuário do aplicativo.
Depois de concluir a configuração, você poderá testar o fluxo de trabalho do aplicativo lógico postando um pacote de exemplo no contêiner sa_UniqueValue para processamento. Dependendo dos requisitos da sua solução, você também poderá modificar qualquer um desses aplicativos lógicos para ter mais processamento.
Gerenciar erros
Se a execução de um aplicativo lógico resultar em erro, um arquivo com o nome originalblobname_response.jso será criado no contêiner bundleserror da conta de armazenamento. Você pode analisar esse arquivo para identificar a causa raiz do erro, corrigi-lo e reenviar o pacote com os recursos com falha.
Tipo de pacote: Batch
O servidor FHIR e as Dataverse Healthcare APIs processam um pacote do tipo lote como um grupo de ações independentes. Como resultado, as respostas indicam o sucesso e o fracasso de cada recurso de forma independente.
De acordo com a especificação FHIR, qualquer recurso com falha resulta em um OperationOutcome com o valor de gravidade definido como erro, enquanto a Dataverse Healthcare API define o msind_requeststatus como 935000002. Para obter mais informações sobre os tipos de status de solicitação, acesse Tipos de status de solicitação.
O fluxo de trabalho do aplicativo lógico analisa as respostas do servidor FHIR e as Dataverse Healthcare APIs. Ele encerrará o fluxo como Com Falha se houver algum recurso que tenha resultado em um erro.
Observação
Atualmente, as Dataverse Healthcare APIs só oferecem suporte a pacotes FHIR dos tipos batch e batch-response.
Configurar repetições
Depois de identificar e corrigir o erro, você pode colocar o pacote de volta no contêiner bundles para reprocessamento.
Repetição em caso de restrição: servidor FHIR
A ação HTTP no fluxo de trabalho do aplicativo lógico que publica no servidor FHIR usa as políticas de repetição da ação HTTP integrada. O valor padrão é uma política de intervalo exponencial definida para repetir quatro vezes. Você pode editar a política de repetição.
Selecione as reticências no canto superior direito do cartão de ação e selecione Configurações.
Em Política de Repetição, altere o valor do campo Tipo.
Repetição em caso de restrição: Dataverse Healthcare APIs
Os limites da API do serviço de proteção afetam as Dataverse Healthcare APIs. Se uma solicitação para as Dataverse Healthcare APIs for limitada, o fluxo de trabalho do aplicativo lógico tentará novamente três vezes (por padrão) no intervalo Retry-After especificado pela API no cabeçalho de resposta. Você pode editar a contagem de novas tentativas e o intervalo.
Para alterar a contagem de repetições, edite o valor Contagem na ação Loop até.
Para alterar o intervalo, edite o valor Contagem na ação Atrasar.
Proteger Aplicativos Lógicos
Depois que terminar de configurar e testar o aplicativo lógico, você poderá bloquear o rastreamento protegendo as ações de entradas e saídas. Para saber mais, acesse Proteger o Aplicativo Lógico.