Dynamic DataWeave para acesso seguro aos dados EHR da UCSF

Dynamic DataWeave para acesso seguro aos dados EHR da UCSF

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Veera Gopalakrishnan, engenheira de integração de sistemas, e Swarnim Ranjitkar, engenheiro sênior de software da Universidade da Califórnia, São Francisco (UCSF), têm mais de cinco anos de experiência na MuleSoft. A Veera apresentou um caso de uso UCSF e MuleSoft durante nosso Meetup de desenvolvedores no MuleSoft CONNECT Digital Americas. Aqui, Veera e Swarnim fornecem uma explicação detalhada de como o UCSF usa scripts dinâmicos do DataWeave e a plataforma Salesforce para acesso seguro aos dados do Registro Eletrônico de Saúde (EHR) por meio de APIs.

A história da tecnologia EHR

A tecnologia EHR usa vários padrões e estruturas diferentes para desenvolvedores que evoluíram ao longo dos anos. A organização HL7 criou o padrão de mensagens HL7 v2.x para troca eletrônica de dados no domínio clínico. Infelizmente para novos desenvolvedores, a estrutura é difícil de entender, a menos que eles trabalhem no setor de saúde por muitos anos, porque os dados são difíceis de decifrar. À medida que a Representational State Transfer (REST) ​​se tornou popular e amplamente utilizada em muitos setores, a organização HL7 criou o padrão Fast Healthcare Interoperability Resources (FHIR).

O FHIR é baseado em modelos de recursos REST, o que significa que as informações clínicas são representadas como recursos diferentes, como “recurso do paciente”, “recurso de resultados de laboratório” ou “recurso de alergia”. Usando esse modelo de troca de dados do FHIR, as organizações do HL7 adotaram uma estrutura padrão denominada SMART (Aplicações Médicas Substituíveis e Tecnologias Reutilizáveis) no FHIR para integrar facilmente aplicativos de terceiros ao sistema EHR. Isso visa ajudar os médicos a tomar decisões informadas no ponto de atendimento.

Desafios colocados pelas APIs de fornecedores de EHR

Na UCSF, enfrentamos muitas limitações e desafios com essa nova estrutura de RSE, dificultando nossa capacidade de oferecer a melhor experiência para o paciente. Especificamente, quando os fornecedores de EHR começaram a desenvolver APIs, ele não ofereceu o nível de segurança desejado para expor nossos dados por meio de APIs. Na UCSF, usamos nosso EHR para armazenar dados de pacientes de hospitais afiliados e não queremos expor os dados desses pacientes por meio das APIs de EHR. Em vez disso, queremos apenas expor os dados de pacientes UCSF. Isso significava que precisávamos adicionar segurança adicional ao que o EHR fornecia.

Para fazer isso, tivemos que criar processos e lógica para filtrar os pacientes não UCSF por meio dessas APIs. Isso representou um desafio, no entanto, como além do FHIR, o fornecedor também tinha um conjunto mais antigo de APIs que foram desenvolvidas por longos períodos de tempo e por muitos desenvolvedores diferentes. Assim, eles careciam da padronização e da segurança exigidas pelo UCSF. Isso nos levou a gastar mais tempo protegendo e publicando as APIs do fornecedor de EHR por meio do proxy.

Abordagem de proxy inicial da UCSF

Usando o MuleSoft, desenvolvemos proxies para a tecnologia EHR. Criamos três proxies diferentes para expor as APIs do EHR:

  • APIs de proxy FHIR
  • APIs de proxy não FHIR
  • Proxy de APIs personalizadas (para as APIs desenvolvidas na UCSF para expor os dados EHR que não estão disponíveis nas APIs do fornecedor)

Nossas APIs personalizadas foram desenvolvidas na plataforma Anypoint, permitindo adicionar toda a segurança necessária para nossa organização no proxy. A razão pela qual criamos esses três proxies foi encapsular segurança adicional, incluir validação e redação de dados e ter análises de API para UCSF.

Sem entrar em muitos detalhes, queríamos compartilhar com você três aplicativos diferentes; NEWT (SMART on FHIR App), Luma (aplicativo de auto-agendamento de pacientes) e Eureka (aplicativo de pesquisa usando integração sistema a sistema) que exemplificam os aplicativos e sistemas que precisamos integrar ao sistema EHR usando os proxies da API do EHR. No entanto, essa abordagem inicial tinha limitações.

Desafios com a abordagem de proxy inicial

Inicialmente, instalamos e incorporamos todas as regras de validação e redação escritas no fluxo Mule às nossas APIs. No entanto, quando desejamos adicionar mais aplicativos, havia requisitos diferentes para validação e redação de dados que variavam de acordo com o cliente. Além disso, a maioria das APIs tinha escopo limitado e não possuía filtragem ou validação de dados exigida pelo UCSF. Tivemos que incorporar manualmente a lógica no fluxo do proxy. No entanto, como o incluímos no fluxo, adicionar novos requisitos ou fazer alterações no próprio fluxo foi extremamente desafiador. Como resultado, experimentamos estas limitações:

  • Capacidade limitada de fazer alterações porque demorou tanto.
  • Todas as alterações em nosso primeiro proxy da API foram manuais e exigiram muitas alterações de codificação por requisitos de cada cliente da API.
  • Houve alta demanda e muitos pontos problemáticos que levaram a clientes API insatisfeitos e frustrados.
  • Foi extremamente difícil de manter.

Começamos a pensar: “Por que não podemos extrair todas essas regras de validação de dados lógicos e regras de extração de dados em tabelas ou arquivos separados que podem nos ajudar a fazer alterações facilmente?” Por fim, criamos proxies dinâmicos usando as tabelas de metadados personalizados do DataWeave e do Salesforce para resolver esses problemas prementes de integração.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Externalizando scripts do DataWeave e tabelas de metadados personalizados do Salesforce

Como parte desse esforço, criamos um proxy dinâmico. O fluxograma abaixo mostra como as solicitações recebidas são verificadas, o processo de validação usando scripts DataWeave externalizados ou expressões MEL, como as chamadas para a API do EHR são feitas e, por último, o processo de redação de dados.

Começamos extraindo os scripts do DataWeave e armazenando-os em uma tabela de metadados personalizados do Salesforce. A validação de dados está incluída para nos ajudar a definir requisitos diferentes para cada cliente da API e podemos redigir quaisquer dados confidenciais para clientes específicos. Agora, podemos fazer alterações em tempo real e é mais fácil de manter. Além disso, o sistema lê essas configurações e as carrega nas memórias, para que não precisemos ir ao Salesforce toda vez que processamos solicitações de API, criando assim um sistema de pesquisa dinâmico. No geral, nosso desempenho melhora, podemos fazer alterações em tempo real e ativar / desativar scripts quando necessário. A imagem abaixo é um exemplo de scripts do DataWeave e verificações de validação:

Aqui está um trecho de código de amostra usado para executar verificações de validação:

Exemplo de script de redação de resposta:

Com base no fato de a resposta da API precisar ser redigida para um cliente específico da API, conforme a configuração armazenada na tabela externa, podemos aplicar uma regra de redução de dados usando o código a seguir:

Além disso, você pode ver como armazenamos os scripts externos do DataWeave nas tabelas de metadados personalizados do Salesforce:

Armazenamos expressões de validação para determinar se podemos verificar itens extras, como se for um nulo. Usando esse método, podemos verificar todas as regras de validação de um cliente específico quando a chamada chega através do fluxo do Mule.

Benefícios do DataWeave dinâmico

Armazenando nossos scripts DataWeave na tabela externa, podemos fazer alterações mais rapidamente e sem precisar da ajuda de outros desenvolvedores. Agora, é muito fácil fazer alterações nas regras de validação e redação de dados. Isso fornece flexibilidade e podemos integrar novos aplicativos que desejam usar esses proxies do Mule muito mais rapidamente. Além disso, temos uma resposta mais rápida para nossos clientes de API. Custa-nos menos e nossa equipe é mais eficiente, pois podemos nos concentrar em outros trabalhos importantes, em vez de gastar esforços na alteração desses fluxos de proxy. Nossos fluxos são mais fáceis de manter e os desenvolvedores de aplicativos que desejam usar essas APIs são mais felizes e capazes de ser mais produtivos. Ao utilizar a plataforma Anypoint, a UCSF pode garantir acesso e segurança adequados aos dados de nossos pacientes, continuando a melhorar as experiências de nossos pacientes.

Se você quiser assistir a minha apresentação no Meetup de desenvolvedores no MuleSoft CONNECT Digital Americas, pode encontrar a gravação e recapitular aqui!


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso