Entenda o que é FHIR e a sua importância para o Open Health

As iniciativas de intercâmbio de dados no setor de saúde, por meio de padrões abertos de APIs padronizados (uma parte importante do Open Health), estão crescendo rapidamente e globalmente. Tudo isso junto com a crescente disponibilidade de dados e históricos de pacientes que já são compartilhados entre as instituições e governos.

Desde uma pandemia, a OMS (Organização Mundial da Saúde) tem fomentado fortemente novas abordagens de pesquisa e colaboração, como quais exigem o compartilhamento de dados em benefício da sociedade. As cooperativas de dados de saúde (HDCs, "Health Data Cooperative", em inglês) são uma dessas abordagens. Nelas, os dados são administrados pelos cidadãos que participam dos HDCs. Desta forma, eles permanecem disponíveis para a requisição dentro dos serviços de saúde.

Tudo isso requer o estabelecimento de interfaces de compartilhamento entre as diversas instituições envolvidas, privadas e públicas.

Atualmente, o principal "motor" de intercâmbio de dados utilizando APIs abertas de saúde é a especificação FHIR (Recursos de interoperabilidade rápida de saúde, na sigla em inglês), que é um padrão de saúde para representar e trocar informações médicas por meio de APIs.

Um recurso FHIR pode conter dados sobre um paciente, um dispositivo, uma observação do médico que atendeu ao paciente, diagnósticos, recomendações terapêuticas e muito mais.

O Ministério da Saúde do Brasil, ao instituir a RNDS (Rede Nacional de Dados em Saúde) adotou oficialmente o padrão FHIR. Assim, nosso país ambiciona que, ao longo de sua evolução, a RNDS se torne uma plataforma informacional de alta disponibilidade, segura, flexível e que possibilite o tratamento dos dados coletados, além de auxiliar a pesquisa e fomentar o surgimento de novos serviços para os usuários.

Uma visão das APIs FHIR

O FHIR especifica um conjunto básico de recursos, que podem ser combinados de várias maneiras para atender às demandas do modelo de dados dos provedores de saúde. Ele também fornece representações de observações e documentos.

O padrão FHIR é fundamentado por 3 princípios:

1. Fornecer uma estrutura flexível para interoperabilidade;
2. Evitar uma complexidade excessiva;
3. Suportar padrões, mas não exigir especificações muito rígidas.

Desta forma, o FHIR não tem como objetivo abranger todos os documentos ou tipos de dados possíveis. Em vez disso, visa inicialmente dar suporte para a maioria dos casos de uso médico, como o intercâmbio de prontuários e dados de pacientes.

Contudo, o FHIR define que como extensões não podem desfigurar ou alterar uma estrutura das APIs (os "recursos"). Assim, apenas após atender a estes requisitos básicos de interoperabilidade, é possível que uma implementação de FHIR seja estendida para as necessidades médicas ou organizacionais adicionais.

O FHIR é baseado em "recursos", que são os blocos de construção comuns para todos como trocas usando APIs. Os recursos FHIR são uma representação em nível de instância para algum tipo de assistência médica. Todos estes recursos têm as seguintes características em comum:

• URL que identifica o recurso;
• Metadados comuns;
• Resumo XHTML legível por humanos;
• Conjunto de elementos de dados definidos;
• Estrutura de extensibilidade para dar suporte a novas demandas de dados específicos na área da saúde.

As instâncias de recursos são representadas como XML ou JSON e atualmente existem 145 tipos de recursos diferentes definidos na especificação FHIR 4(clique aqui para mais detalhes).

Extensibilidade

Mesmo com regulações globais para o setor, ocorrem grandes variações de jurisdições geopolíticas do setor de saúde sem que haja uma autoridade central para importar práticas comuns. Tendo isso em mente, os criadores da especificação FHIR definiram uma estrutura de extensão e de gerenciamento para a variabilidade.

Um aspecto importante que foi considerado ao criar o FHIR é que a mesma informação deve ser representada de forma diferente e com variados níveis de detalhe e granularidade.

Por exemplo, em alguns casos, uma medição de pressão arterial pode ser apenas uma simples observação, enquanto em outros pode ser um rico conjunto de dados altamente definidos que podem incluir vocabulários controlados para postura, exercícios correlacionados ao paciente, etc.

Para suportar esta crescente granularidade, os recursos FHIR se concentram nos casos de uso geral e comum, mas o conteúdo mais rico e específico pode ser suportado e padronizado definindo "perfis" nos tipos de recursos básicos.

Portanto, a especificação FHIR deve ser entendida como uma "especificação de plataforma", pois ela cria uma plataforma ou base comum, mas frequentemente extensível. Como conseqüência, esta especificação geralmente requer maior adaptação a contextos particulares de uso.

Normalmente, essas adaptações especificam:

• Regras sobre quais elementos de recurso são ou não usados e quais elementos adicionais são adicionados que não fazem parte da especificação base;
• Regras sobre quais recursos de API são usados e de qual forma;
• Regras sobre quais terminologias são usadas em elementos específicos;
• As descrições de como os elementos do recurso e os recursos da API são mapeados para requisitos e/ou implementações locais.

É importante observar que, devido à natureza extremamente complexa e distribuída do ecossistema de saúde, existem vários conjuntos sobrepostos de adaptações - por domínio de saúde, por país, por instituição e/ou por fornecedor/implementação.

Entre os principais artefatos do FHIR que suportam esta extensibilidade estão:  

• Guia de Implementação: conjunto coerente e limitado de adaptações que são publicadas como uma única unidade. A validação não ocorre no contexto do Guia de Implementação;
• Pacote (Pacote): grupo de adaptações relacionadas que são publicadas por um Guia de Implementação;
• Recurso de Conformidade: único recurso em um pacote que cria regras sobre como uma implementação funciona.

Perfil (Perfis): um conjunto de restrições em um recurso representado

Em resumo, a definição de perfis é um esforço na modelagem de informação em saúde. Isso acarreta, para os desenvolvedores que desejarem criar integrações via FHIR, estudar inicialmente os perfis específicos e os recursos a serem trocados. Afinal, toda a troca de dados deverá estar em conformidade com os perfis definidos na implementação FHIR criada.

No Brasil, RNDS é uma plataforma nacional de interoperabilidade em saúde instituída pelo governo brasileiro. Ela tem o objetivo de promover a troca de informações entre os pontos da Rede de Atenção à Saúde ao permitir a transição e continuidade do cuidado nos setores públicos e privados. A RNDS é uma iniciativa do Departamento de Informática do SUS (DATASUS), da Secretaria Executiva do Ministério da Saúde.

Como a Sensedia pode ajudar sua instituição a realizar esta jornada de transformação e integração

A Sensedia, como líder global em projetos de gestão e integração por meio de APIs abertas, tem atuado fortemente no suporte técnico à padronização e criação deste modelo, com intensa atuação nos grupos técnicos que definem estas APIs no Brasil.

No caso de Open Banking e Open Insurance, a Sensedia tem desempenhado papel decisivo em fornecer insumos para a especificação destas APIs pelo BACEN (Banco Central do Brasil) e SUSEP (Superintendência de Seguros Privados), respectivamente.

Portanto, sendo participante ativa do processo de criação e teste de APIs abertas no Brasil, a Sensedia adquiriu um profundo conhecimento regulatório e técnico - atualmente, são cerca de 40 clientes, entre bancos e seguradoras, que adotam uma plataforma Open Finance da Sensedia.

Reusando a ampla experiência adquirida nestes casos de sucesso em integração via APIs abertas, a Sensedia conta com um grupo de especialistas técnicos para atuar nas implementações de Open Health no Brasil e realizar a integração de instituições públicas e privadas à RNDS via FHIR .

Nossos especialistas poderão guiar sua empresa ou instituição por toda a jornada de adoção tecnológica das APIs FHIR, com:

• Entendimento regulatório e técnico dos padrões brasileiros e da RNDS;
• Mapeamento das trocas de dados a serem priorizadas;
• Implementação das APIs para integração aos demais órgãos de saúde, privados e públicos;
• Integração interna aos sistemas legados (internos);
• Testes de interoperabilidade com os demais órgãos;
• Finalmente, certificação oficial da solução.

O Open Health no Brasil

Para o futuro, espera-se que os pacientes não precisem refazer exames pela falta de informação sobre seus atendimentos em outros hospitais. Com o compartilhamento aberto de dados dentro da saúde, seu histórico médico estará disponível de maneira integrada, contendo as informações geradas por outras instituições médicas e centros de diagnóstico nos quais já foi atendido previamente.

Neste cenário, cada médico que atender ao paciente terá acesso ao seu prontuário e histórico completo e não será mais necessário solicitar a realização de exames em duplicidade (sobrecarregando o sistema público de saúde). Estes são apenas alguns dos problemas que o Open Health pretende solucionar.

O nosso objetivo é ajudar sua empresa ou instituição a realizar a integração a demais entes públicos e privados por meio das APIs FHIR de forma segura, escalável, flexível, além de permitir que o seu tempo se concentre nos intercâmbios de dados críticos e gradualmente estenda estas funcionalidades.

‍