Ir para a página principal

Esta página foi traduzida automaticamente e pode conter erros

DHIS2 e FHIR

O DHIS2 suporta a utilização de FHIR em implementações de saúde.
Os metadados nos sistemas DHIS2 podem ser mapeados para perfis FHIR normalizados, proporcionando compatibilidade com perfis de pacientes FHIR nacionais e diretrizes SMART da OMS.
Nesta página, podes saber mais sobre ferramentas e abordagens para o intercâmbio e integração de dados DHIS2 utilizando FHIR

Ir para uma secção desta página

    O que é FHIR?

    O FHIR (Fast Healthcare Interoperability Resources) é uma norma que é organizada pelo grupo de gestão FHIR no âmbito do consórcio HL7.
    A partir da descrição do produto HL7 FHIR:

    A FHIR é uma norma de interoperabilidade destinada a facilitar a troca de informações sobre cuidados de saúde entre prestadores de cuidados de saúde, doentes, prestadores de cuidados de saúde, pagadores, investigadores e qualquer outra pessoa envolvida no ecossistema de cuidados de saúde.
    Consiste em duas partes principais – um modelo de conteúdos sob a forma de “recursos” e uma especificação para o intercâmbio destes recursos sob a forma de interfaces RESTful em tempo real, bem como de mensagens e documentos.

    Embora o sistema legado HL7 não tenha desaparecido, o FHIR utiliza paradigmas RESTful que são mais familiares aos programadores modernos de aplicações Web.
    Nos últimos anos, registou-se um aumento do interesse e da aceitação, com os principais fornecedores, como a Microsoft, a Google, a Epic e outros, a criarem ferramentas e interfaces compatíveis com FHIR.
    Também tem havido um interesse e um trabalho consideráveis na comunidade internacional de desenvolvimento, incluindo a comunidade OpenHIE e os grupos de trabalho técnicos da OMS.
    A FHIR define uma ontologia rica de recursos de base, como Patient, Observation, ValueSet, CodeSystem, etc.
    A rápida evolução da FHIR resultou na necessidade de estabelecer diferentes níveis de maturidade para diferentes recursos.
    Assim, embora esteja em constante desenvolvimento, há um subconjunto crescente de recursos que alcançaram o estatuto normativo.
    Os recursos de base são definidos tendo em mente a extensibilidade e a personalização.
    Os campos e codificações necessários para descrever um doente nos Estados Unidos, por exemplo, podem ser substancialmente diferentes dos necessários na Noruega ou na Serra Leoa.
    O processo de personalização, extensão e limitação dos recursos de base é conhecido como definição de perfis. O estabelecimento de um consenso em torno dos perfis é uma atividade fundamental para estabelecer a interoperabilidade real entre os sistemas participantes.
    Em termos de DHIS2, isto é semelhante às Tracked Entity Instances (TEIs) – o facto de dois sistemas DHIS2 suportarem TEIs não implica necessariamente que possam trocar dados sem harmonizar atributos, conjuntos de opções, etc.
    Os recursos FHIR de base são geridos pelo grupo de gestão HL7 FHIR, mas qualquer organização pode criar e publicar perfis.
    Assim, por exemplo, é uma atividade comum para as jurisdições nacionais criarem perfis nacionais.
    Tem havido algumas tentativas de harmonizar estas actividades através de esforços como o Resumo Internacional do Doente. Um conceito relacionado com o perfil FHIR é o Guia de Implementação (IG) FHIR.
    Os IG fornecem uma forma consistente de descrever colecções relacionadas de recursos FHIR com perfil para abordar domínios de problemas específicos.
    Normalmente, incorporam artefactos legíveis por máquina, bem como texto narrativo, exemplos, etc.

    DHIS2 no FHIR

    O DHIS2, tal como quase todos os sistemas de software digital de saúde de grande dimensão e já estabelecidos, é construído em torno de um modelo de dados que evoluiu ao longo de muitos anos para responder eficazmente a uma grande variedade de casos de utilização no domínio da saúde e não só.
    O modelo é estável, robusto e bem documentado.
    Encaramos a FHIR como uma norma de interoperabilidade e não como um substituto do nosso modelo interno.
    O desafio consiste, portanto, em criar mapeamentos eficazes entre os recursos do modelo DHIS2 e os recursos equivalentes ou semelhantes do modelo FHIR.
    Este desafio não é trivial, uma vez que ambos os modelos são altamente personalizáveis e extensíveis.
    Por isso, abordamos o problema de forma incremental e iterativa, preferindo basear a nossa abordagem em aplicações concretas.
    Tecnicamente, isto implica a utilização de transformações, interfaces e fachadas, que traduzem os recursos FHIR para o modelo de dados DHIS2 subjacente, utilizando uma estrutura de integração como o Apache Camel (por exemplo, transformando uma Tracked Entity Instance (TEI) num perfil de doente FHIR).
    Este processo é descrito com mais pormenor na secção sobre tecnologia.
    Esta abordagem já foi utilizada com êxito no mundo real.
    Por exemplo, como parte do nosso trabalho com a implementação da segurança regional das vacinas da OPAS (ESAVI), que utiliza uma versão personalizada do pacote de metadados do DHIS2 AEFI Tracker para recolher dados que são mapeados num questionário com perfil FHIR para facilitar a partilha de dados com outros sistemas e que pode, subsequentemente, apoiar a compatibilidade com a base de dados global de farmacovigilância Vigibase.
    Este é um bom exemplo de um processo de interoperabilidade que se baseia em necessidades do mundo real num país específico ou num contexto regional, ao contrário dos projectos que se baseiam em esquemas abstractos, que tendem a ser mais difíceis e a ter menos impacto.
    Em todos os casos que explorámos até agora, conseguimos transformar com êxito os dados do DHIS2 em FHIR.
    A equipa de integração do DHIS2 continua a trabalhar com parceiros locais e globais em necessidades específicas de FHIR e no desenvolvimento de abordagens genéricas que podem ser partilhadas e adaptadas.
    Se tiveres um problema que precises de resolver com FHIR, entra em contacto connosco: integration@dhis2.org

    Exemplos de capacidades actuais

    Mapeamento para Questionário / QuestionnaireResponse: Os Questionários FHIR fornecem um mecanismo conveniente para a interoperabilidade entre sistemas que não partilham necessariamente a mesma coleção rica de recursos FHIR específicos do domínio.
    Os repositórios FHIR nativos podem mapear questionários utilizando, por exemplo, SDC (Structured data Capture).
    Do mesmo modo, do lado do DHIS2, podemos mapear o Tracker e agregar formulários de introdução de dados a Questionários.
    O Questionário abstrai a diferença de modelo de dados em ambos os lados.
    Como já foi referido, esta abordagem foi utilizada eficazmente pela OPAS para o intercâmbio de dados de rastreio.
    Também estamos atualmente a trabalhar num mapeamento normalizado entre os conjuntos de dados agregados do DHIS2 e os Questionários FHIR. Mapeamento para o recurso do paciente: Um perfil FHIR específico em que nos concentrámos foi o International Patient Standard (IPS).
    A equipa do DHIS2 traduziu os metadados do DHIS2 Tracker para uma carga útil do paciente em conformidade com o IPS.
    Isto permitir-nos-á, eventualmente, apoiar a importação e a exportação de dados demográficos dos doentes (por exemplo, no encaminhamento de doentes sob a forma de um resumo internacional de doentes). Expõe os metadados do DHIS2 como recursos FHIR: Desenvolvemos transformações para expressar conjuntos de opções e unidades de organização do DHIS2 como conjuntos de valores FHIR e recursos compatíveis com mCSD.
    Generalizando a partir desta experiência, estamos a trabalhar no sentido de as implementações poderem expor e descrever os seus metadados estruturais de forma mais geral utilizando o FHIR.
    Utilizando as ferramentas que desenvolvemos até agora, é possível pegar em alguns aspectos dos metadados do DHIS2 e produzir um guia de implementação FHIR a partir deles.
    Isto significa que os países e as organizações que utilizam o DHIS2 como ambiente de criação nacional (para a recolha de dados sobre os doentes, relatórios agregados, etc.) – que é um papel típico do DHIS2 na arquitetura da informação digital de saúde de um país – podem gerar perfis FHIR que representam a informação que se encontra na sua instância do DHIS2.

    Tecnologia

    A equipa de integração do DHIS2 utiliza o middleware de código aberto Apache Camel para uma variedade de projectos de integração.
    Para facilitar a vida dos engenheiros de integração, desenvolvemos uma biblioteca de cliente java DHIS2 e um componente DHIS2 Camel, que facilita a criação de rotas entre os pontos finais DHIS2 e outros componentes Camel (como FHIR, HL7v2x, etc.).
    Considerámo-lo particularmente útil para suportar formatos e transformações de dados FHIR.
    Existem outras opções de middleware, mas selecionámos o Apache Camel devido à sua flexibilidade, maturidade e utilização extensiva numa variedade de indústrias, o que significa que já existem muitos conectores que podem ajudar a ligar o DHIS2 a qualquer sistema com o qual os países o queiram integrar.
    Há vários exemplos de utilizações semelhantes do Camel para transformar dados de saúde, incluindo a ferramenta ETL OpenMRS, a ponte OpenEHR FHIR e a plataforma de integração Open eHealth. Esta abordagem funciona através da comunicação com a instância DHIS2 num dos lados do conetor Apache Camel e, em seguida, efectua uma transformação que traduz os dados DHIS2 para o formato FHIR.
    Existem dois métodos para o fazer:

    1. Soneto de dados: Este é um processador para mapear um formato de dados para outro.
      Por exemplo, podes escrever um mapa Data Sonnet que traduza uma Instância de Entidade Rastreada para um Resumo Internacional do Doente FHIR.
      Esta tem sido a abordagem mais popular até agora e é utilizada pela equipa do Pacote de Metadados DHIS2, entre outros.
      Uma vez criados os mapas do Data Sonnet, os utilizadores podem modificá-los sem terem de editar qualquer código, bastando atualizar os mapeamentos relevantes.
      A equipa de integração do DHIS2 criou exemplos e tutoriais para o Data Sonnet, que podem ser consultados abaixo.
    2. Código Java: A transformação de dados também pode ser efectuada processualmente utilizando código Java com a biblioteca HAPI FHIR.
      O Apache Camel tem um componente FHIR que inclui esta biblioteca.

    Explora as ferramentas e exemplos actuais de integração DHIS2-FHIR

    Componente DHIS2 Camel

    Um wrapper Apache Camel para a Biblioteca de Clientes DHIS2 que permite aos utilizadores utilizá-la em rotas Camel (onde são definidos fluxos de trabalho de integração). Explore no GitHub

    Pacote DHIS2 para FHIR

    Mostra como os recursos DHIS2, como as unidades organizacionais, podem ser convertidos em pacotes FHIR antes de serem carregados para um servidor FHIR como o HAPI FHIR. Explore no GitHub

    Pacote DHIS2 para FHIR com DataSonnet

    Mostra como os recursos DHIS2, como as unidades organizacionais, podem ser mapeados para pacotes FHIR com o DataSonnet antes de serem carregados para um servidor FHIR como o HAPI FHIR. Explore no GitHub

    Contacta-nos para suporte de integração FHIR

    A equipa de integração do DHIS2 está entusiasmada por trabalhar com os parceiros nacionais para responder a necessidades concretas de FHIR.
    A nossa abordagem incremental ao FHIR significa que estamos dependentes de casos de utilização do mundo real para impulsionar o desenvolvimento.
    Se tiveres um projeto específico de integração FHIR relacionado com o DHIS2, entra em contacto connosco: integration@dhis2.org