Fachada FHIR®: é preciso reescrever tudo?

A adoção do padrão HL7® FHIR® tem ampliado as possibilidades de integração, compartilhamento e uso estruturado de informações em saúde. No entanto, grande parte das organizações ainda depende de sistemas legados desenvolvidos com tecnologias e modelos de dados proprietários.

Esses sistemas frequentemente sustentam processos críticos, armazenam grandes volumes de informações e permanecem essenciais para a operação das instituições. Por isso, sua substituição imediata pode ser tecnicamente complexa, financeiramente inviável ou representar riscos à continuidade dos serviços.

Diante desse cenário, surge uma questão importante:

Como disponibilizar os dados de um sistema existente por meio de uma interface FHIR sem precisar substituir ou reescrever toda a aplicação?

Uma das estratégias possíveis é a implementação de uma fachada FHIR.

O que é uma fachada FHIR?

Uma fachada FHIR é uma camada de interoperabilidade posicionada entre os sistemas consumidores e uma aplicação, API ou banco de dados já existente.

Sua função é disponibilizar uma interface compatível com o padrão FHIR, mesmo quando o sistema de origem não foi originalmente desenvolvido para trabalhar com esse padrão.

De forma simplificada: Cliente FHIR → Fachada FHIR → Sistema legado

Quando um cliente envia uma requisição FHIR, a fachada interpreta essa solicitação e a traduz para o modelo, a API ou a estrutura de dados utilizada pelo sistema de origem. Em seguida, os dados retornados pelo sistema são transformados em recursos FHIR e disponibilizados ao cliente em um formato padronizado.

A fachada atua, portanto, como um adaptador entre dois universos:

• o modelo padronizado do HL7® FHIR®;
• o modelo proprietário utilizado pelo sistema existente.

Por exemplo, um cliente pode executar a seguinte operação:

GET {{endpoint}}/Patient/123456/$everything

A fachada recebe essa requisição, consulta o sistema de origem por meio de sua API ou de seu banco de dados e transforma as informações recuperadas em recursos FHIR.

Nesse exemplo, a resposta pode ser apresentada em um Bundle contendo o recurso Patient e outros recursos relacionados, de acordo com os dados disponíveis e com a implementação da operação $everything.

Dessa forma, o consumidor utiliza uma interface FHIR sem precisar conhecer a estrutura interna do sistema legado.

Por que utilizar uma fachada FHIR?

A principal vantagem dessa abordagem é permitir uma adoção gradual do FHIR.

Em vez de substituir integralmente uma aplicação consolidada, a organização pode adicionar uma camada padronizada de interoperabilidade sobre a infraestrutura existente.

Essa estratégia pode:

• preservar sistemas que continuam atendendo às necessidades operacionais;
• reduzir os riscos de uma migração completa;
• evitar a reescrita imediata de aplicações complexas;
• disponibilizar dados para novas aplicações e serviços;
• reduzir integrações proprietárias ponto a ponto;
• facilitar a adoção progressiva de padrões de interoperabilidade.

Nesse contexto, a fachada FHIR permite iniciar a implementação gradual da interoperabilidade baseada no padrão FHIR sem interromper os processos existentes.

O que uma fachada FHIR bem projetada precisa considerar?

A implementação de uma fachada FHIR não deve ser compreendida apenas como uma conversão técnica de requisições e respostas.

Uma fachada bem projetada precisa considerar:

• o modelo de dados do sistema de origem;
• os recursos FHIR que serão disponibilizados;
• os Perfis e Guias de Implementação adotados;
• os mapeamentos terminológicos;
• os identificadores;
• as regras de negócio;
• a segurança;
• a qualidade e a governança dos dados.

Portanto, uma fachada FHIR pode evitar a necessidade de reescrever toda a aplicação, mas ainda exige uma compreensão profunda dos dois universos que pretende conectar.

A interoperabilidade não depende apenas de expor dados por meio de uma nova API. Ela depende de transformar esses dados de maneira estruturada, consistente e semanticamente compreensível.