HL7 FHIR: o que gestores hospitalares precisam saber antes de implementar

Os sistemas do seu hospital conseguem trocar informações e interpretar os dados recebidos sem depender de redigitação? Essa é a necessidade que coloca o HL7 FHIR entre os principais padrões de interoperabilidade da saúde digital.

FHIR é a sigla de Fast Healthcare Interoperability Resources. Desenvolvido pela HL7, o padrão estabelece uma forma comum de representar e compartilhar informações de saúde entre prontuários eletrônicos, laboratórios e outras aplicações autorizadas.

Na prática, o FHIR pode permitir que um resultado de exame seja enviado ao prontuário no formato esperado pelo sistema receptor. Isso ajuda a reduzir integrações improvisadas e favorece a continuidade do cuidado, especialmente quando o paciente circula entre diferentes serviços.

Contudo, adotar o padrão não significa apenas contratar uma API ou substituir os sistemas existentes. O hospital precisa definir quais informações serão compartilhadas, quem poderá acessá-las e quais processos devem ser integrados.

Neste guia, você entenderá como o FHIR HL7 funciona no ambiente hospitalar, sua relação com a Rede Nacional de Dados em Saúde (RNDS) e o que deve ser avaliado antes de iniciar um projeto de implementação.

O que é HL7 FHIR?

O HL7 FHIR é um padrão para representar e trocar informações eletrônicas de saúde entre sistemas diferentes. Seu objetivo é permitir que cada aplicação reconheça o significado dos dados recebidos, mesmo quando os sistemas foram desenvolvidos por empresas distintas.

A sigla FHIR significa Fast Healthcare Interoperability Resources, traduzida como Recursos Rápidos de Interoperabilidade em Saúde. O padrão foi desenvolvido pela Health Level Seven International, organização internacional responsável por normas usadas na comunicação entre sistemas de saúde.

O FHIR organiza as informações em componentes chamados recursos. Existem recursos para representar um paciente, um atendimento, um resultado de exame e outras informações clínicas ou administrativas. Essa organização cria uma linguagem comum para os sistemas envolvidos.

Assim, em vez de cada fornecedor definir uma estrutura própria para identificar um paciente ou registrar uma observação clínica, as aplicações podem seguir modelos compartilhados. Isso reduz a dependência de integrações construídas exclusivamente para conectar dois sistemas.

O padrão também foi projetado para trabalhar com tecnologias amplamente utilizadas na web, como APIs, HTTP e formatos estruturados de dados. Essa característica facilita sua adoção em prontuários, aplicativos e ambientes em nuvem sem limitar o FHIR a uma única arquitetura tecnológica.

Leia mais: Interoperabilidade: pilar da gestão hospitalar moderna

Qual é a diferença entre HL7 e FHIR?

HL7 e FHIR não são padrões concorrentes. A Health Level Seven International, geralmente chamada apenas de HL7, é a organização que desenvolve e mantém uma família de padrões para a troca de informações de saúde. FHIR é um dos padrões criados dentro desse ecossistema.

A confusão acontece porque o termo HL7 também é usado informalmente para se referir ao HL7 Versão 2, presente há décadas em integrações hospitalares. Nesse modelo, a comunicação normalmente ocorre por mensagens disparadas por eventos, como admissão, transferência ou alta de um paciente.

O FHIR adota uma abordagem diferente. Ele representa as informações em recursos que podem ser consultados ou compartilhados por APIs. Isso permite que uma aplicação solicite apenas os dados necessários para determinado processo, respeitando as permissões estabelecidas.

Isso não significa que um hospital precise abandonar imediatamente suas interfaces HL7 V2. Os dois padrões podem coexistir, e sistemas legados podem utilizar uma camada de integração para transformar determinadas mensagens em recursos FHIR.

Um exemplo de FHIR na jornada do paciente

Imagine que um paciente faça um exame em um laboratório externo. Sem uma integração adequada, o resultado pode chegar ao hospital como PDF, ser anexado manualmente ou até permanecer disponível apenas no portal do laboratório.

Com uma integração baseada em HL7 FHIR, o laboratório pode estruturar o resultado de forma padronizada e enviá-lo para uma aplicação autorizada. O sistema hospitalar identifica a qual paciente o exame pertence e registra as informações no local previsto pelo prontuário.

O ganho não está apenas no transporte do dado. O resultado precisa chegar com contexto suficiente para ser localizado e interpretado pelo sistema receptor. Isso envolve elementos como identificação do paciente, tipo de exame e valores observados.

Para o gestor, esse exemplo demonstra o papel do padrão: criar condições para que os dados acompanhem a jornada assistencial sem depender de intervenções manuais em cada etapa. O FHIR não substitui o prontuário ou o sistema laboratorial; ele estabelece uma forma organizada para que essas aplicações se comuniquem.

Mas há um detalhe importante: compreender a finalidade do padrão é apenas o primeiro passo. Para avaliar uma proposta de integração, o gestor também precisa entender, em termos simples, como o FHIR organiza e transporta essas informações.

Como o FHIR permite que sistemas hospitalares troquem dados?

Para que dois sistemas se comuniquem, não basta estabelecer uma conexão entre eles. As aplicações precisam concordar sobre como cada informação será representada e qual significado ela terá.

O HL7 FHIR fornece essa estrutura por meio de recursos padronizados. Cada recurso representa um conceito específico da área da saúde e contém campos próprios para aquele tipo de informação.

Na prática, o fluxo pode ser resumido desta forma: dado hospitalar -> recurso FHIR -> interface de troca -> sistema autorizado.

Uma informação registrada no sistema de origem é organizada conforme o recurso adequado. Depois, ela pode ser enviada ou consultada por outra aplicação, que interpreta o conteúdo seguindo as mesmas regras.

Leia também: Sistema Hospitalar: o que é, como funciona e como escolher

Recursos FHIR: paciente, atendimento e resultado de exame

Um recurso FHIR é uma estrutura usada para representar uma entidade ou um evento relacionado à saúde. Em vez de reunir todo o histórico clínico em um único bloco, o padrão divide as informações em componentes que podem ser relacionados.

Entre os recursos mais comuns em uma operação hospitalar estão:

Imagine uma medição de glicemia realizada durante uma internação. O resultado pode ser representado pelo recurso Observation, relacionado ao paciente por meio de Patient e ao atendimento correspondente por Encounter.

Essa relação evita que o dado seja tratado como um valor isolado. O sistema receptor consegue identificar de quem é o resultado e em qual contexto assistencial ele foi produzido.

Outros recursos podem representar profissionais, medicamentos e procedimentos. Entretanto, o gestor não precisa conhecer todo o catálogo para conduzir o projeto. O ponto central é verificar se os recursos necessários ao caso de uso estão definidos e são realmente suportados pelos sistemas envolvidos.

APIs, perfis e guias de implementação

Os recursos FHIR podem ser compartilhados de diferentes maneiras. Uma das mais conhecidas utiliza APIs REST, tecnologia também presente em aplicativos bancários, plataformas comerciais e diversos serviços digitais.

Por meio de uma API, um sistema autorizado pode solicitar uma informação específica em vez de receber um arquivo com dados que não serão utilizados. A resposta costuma ser estruturada em formatos como JSON ou XML, permitindo que a aplicação processe o conteúdo automaticamente.

Contudo, afirmar que um sistema “possui API FHIR” ainda é insuficiente. É necessário descobrir:

qual versão do padrão é suportada;

quais recursos estão disponíveis;

quais operações podem ser executadas;

que regras de segurança controlam o acesso.

Além da especificação básica, o FHIR utiliza perfis para adaptar os recursos a uma necessidade concreta. Um perfil pode estabelecer campos obrigatórios, terminologias aceitas e restrições aplicáveis a determinado contexto.

Já o guia de implementação reúne as regras necessárias para um caso de uso ou uma realidade nacional. Ele orienta como os recursos e perfis devem ser usados para que diferentes participantes implementem a integração de maneira compatível.

Isso significa que dois fornecedores podem declarar suporte ao mesmo padrão e ainda assim não conseguir trocar dados imediatamente. Se utilizarem versões incompatíveis ou interpretações diferentes, será necessário ajustar a implementação.

Para o gestor hospitalar, a pergunta mais importante não é apenas “o sistema suporta FHIR?”. A pergunta correta é: “Quais fluxos o sistema consegue executar, seguindo qual versão e quais guias de implementação?”

Veja por que isso é importante: a capacidade técnica só produz resultado quando é aplicada a um processo concreto do hospital. É nesse ponto que o FHIR deixa de ser uma especificação e passa a apoiar a operação.

Onde o HL7 FHIR gera valor dentro de um hospital?

O valor do HL7 FHIR aparece quando uma informação precisa sair de um sistema e ser utilizada por outro sem perder seu significado. Isso pode acontecer entre aplicações da própria instituição ou na comunicação com laboratórios e outros participantes da rede assistencial.

O padrão não melhora a operação apenas por estar disponível no software. É preciso aplicá-lo a um processo no qual a fragmentação de dados provoca atrasos, retrabalho ou risco para o paciente.

Por isso, a adoção deve começar por uma situação concreta. Integrar um resultado laboratorial ao prontuário, por exemplo, é um objetivo mais claro do que iniciar um projeto com a meta genérica de “implementar FHIR”.

Casos de uso na jornada assistencial

Um dos principais casos de uso está na integração entre o Prontuário Eletrônico do Paciente (PEP) e o Sistema de Informação Laboratorial (LIS). Quando o resultado fica restrito ao laboratório, a equipe assistencial pode precisar consultar outro portal ou anexar um documento manualmente.

Com uma troca estruturada, o resultado pode ser associado ao paciente correto e apresentado no prontuário dentro do contexto do atendimento. Esse fluxo também favorece o uso posterior das informações em alertas ou indicadores clínicos.

O mesmo raciocínio pode ser aplicado a outras etapas:

O FHIR também pode apoiar integrações internas. Um sistema hospitalar pode compartilhar informações com aplicações de apoio à decisão ou ferramentas desenvolvidas para uma necessidade específica, desde que o acesso seja autorizado.

Essa capacidade reduz a necessidade de criar uma conexão completamente diferente para cada novo sistema. Os recursos definidos podem ser reutilizados em outros fluxos, desde que os requisitos e as permissões sejam compatíveis.

Entretanto, a instituição deve evitar começar pelos casos mais amplos. Um projeto que tenta integrar toda a jornada do paciente de uma só vez acumula dependências e aumenta a dificuldade de identificar a origem dos erros.

O caminho mais seguro é selecionar um fluxo com benefício mensurável. Depois de validar a arquitetura e o processo, a instituição pode ampliar o escopo gradualmente.

Benefícios e limites do padrão FHIR

Quando bem implementado, o HL7 FHIR pode reduzir etapas manuais na troca de informações e facilitar a conexão com novas aplicações. Isso diminui o esforço necessário para localizar dados que antes estavam distribuídos em diferentes sistemas.

Para a equipe assistencial, o benefício pode aparecer na disponibilidade da informação durante o atendimento. Para a gestão, o ganho está na possibilidade de acompanhar processos com dados mais consistentes e menos dependentes de consolidação manual.

Entre os resultados esperados estão:

menor redigitação de informações;

acesso mais rápido a dados relevantes;

melhor continuidade entre serviços;

integração mais previsível com novas aplicações;

reaproveitamento de interfaces padronizadas.

Esses benefícios, porém, dependem da qualidade da implementação. O FHIR padroniza a representação e a troca, mas não corrige automaticamente os dados existentes no hospital.

Se dois cadastros representam o mesmo paciente com informações conflitantes, o padrão não decide sozinho qual registro está correto. O mesmo ocorre quando um exame é registrado com uma terminologia inadequada ou quando campos essenciais não são preenchidos na origem.

O FHIR também não substitui a governança institucional. A organização ainda precisa definir responsáveis pelos dados, critérios de qualidade e regras de acesso. Sem essas decisões, uma integração tecnicamente funcional pode apenas transportar inconsistências com mais velocidade.

Portanto, o resultado não deve ser medido apenas pelo número de recursos implementados ou APIs publicadas. Uma iniciativa de interoperabilidade gera valor quando melhora um processo hospitalar verificável, sem comprometer a segurança ou aumentar o trabalho das equipes.

Mas o valor operacional não é o único critério. No Brasil, a instituição também precisa considerar como o padrão se relaciona com a infraestrutura nacional e com a proteção dos dados de saúde.

Como HL7 FHIR, RNDS, BR Core e LGPD se relacionam no Brasil?

No Brasil, a adoção do HL7 FHIR está diretamente relacionada ao avanço da interoperabilidade nacional. O padrão é utilizado pela Rede Nacional de Dados em Saúde (RNDS), plataforma oficial do Ministério da Saúde para a troca de informações entre diferentes pontos de atenção.

Isso não significa que todo hospital seja obrigado a converter imediatamente seus sistemas para FHIR. A exigência precisa ser analisada conforme o fluxo de integração, o serviço utilizado e as especificações publicadas para aquele caso de uso.

Além da especificação internacional, as implementações brasileiras precisam considerar regras locais. Identificadores, terminologias e documentos clínicos devem representar corretamente a realidade do sistema de saúde do país.

O papel da RNDS e do BR Core

A Rede Nacional de Dados em Saúde permite que estabelecimentos autorizados compartilhem informações relacionadas ao atendimento e consultem registros produzidos por outros participantes. O objetivo é favorecer a continuidade do cuidado quando o cidadão utiliza diferentes serviços de saúde.

Na perspectiva de um hospital, a RNDS não substitui o prontuário eletrônico nem administra os processos internos da instituição. Ela funciona como uma infraestrutura nacional de interoperabilidade à qual os sistemas podem se conectar seguindo requisitos específicos.

Entre os documentos clínicos utilizados nesse ecossistema estão registros de atendimento, resultados laboratoriais e sumários de alta. Cada fluxo possui regras próprias sobre a informação esperada e a forma de envio.

O BR Core é um guia de implementação que adapta recursos do HL7 FHIR ao contexto brasileiro. Baseado no FHIR R4, ele estabelece perfis e convenções para representar informações de maneira consistente entre diferentes participantes.

Um recurso internacional como Patient, por exemplo, apresenta uma estrutura geral para representar uma pessoa atendida. O perfil brasileiro pode definir como identificadores e outros elementos devem ser utilizados no país.

Implementar o padrão básico não garante compatibilidade automática com a RNDS. O fornecedor precisa demonstrar que atende ao guia e ao caso de uso aplicável, incluindo os requisitos de validação definidos pelo Ministério da Saúde.

O gestor também deve verificar se o sistema está preparado para acompanhar mudanças nas especificações. Perfis e guias podem evoluir, exigindo atualização técnica e novos testes de conformidade.

Segurança e governança dos dados de saúde

A possibilidade de compartilhar informações não elimina a responsabilidade da instituição sobre os dados tratados. Pelo contrário, uma integração amplia os pontos que precisam ser monitorados e protegidos.

Dados relacionados à saúde são considerados pessoais sensíveis pela Lei Geral de Proteção de Dados (LGPD). Seu tratamento exige uma base legal adequada e deve respeitar a finalidade definida para o processo.

Nesse cenário, o hospital precisa controlar:

• quais aplicações podem acessar os dados;

• quais profissionais possuem autorização;

• que informações são necessárias para cada finalidade;

• como os acessos serão registrados;

• qual procedimento será adotado diante de incidentes.

O HL7 FHIR pode trabalhar com mecanismos modernos de autenticação e autorização. Contudo, FHIR não é uma ferramenta de conformidade com a LGPD e não determina sozinho quem deve acessar cada informação.

Essa definição depende da governança do hospital e da arquitetura utilizada. A instituição precisa aplicar controle por perfil, criptografia durante o tráfego e registros de auditoria compatíveis com o risco do processo.

Leia também: Hospital digital: integração, governança e transformação da gestão

Também é necessário definir responsabilidades no contrato com o fornecedor. O documento deve esclarecer quem opera a infraestrutura, como os incidentes são comunicados e quais medidas são adotadas para preservar a disponibilidade das informações.

Um projeto pode seguir corretamente a estrutura de um recurso FHIR e ainda apresentar falhas graves de segurança. Por isso, conformidade técnica e proteção de dados devem ser verificadas separadamente antes da entrada em produção.

Depois de entender essas responsabilidades, surge uma dúvida comum: a adoção do FHIR exige abandonar os padrões e sistemas que o hospital já utiliza? A resposta depende da função de cada tecnologia.

FHIR substitui HL7 V2, TISS ou DICOM?

A adoção do HL7 FHIR não elimina automaticamente os padrões que já fazem parte da operação hospitalar. Cada um foi criado para atender a necessidades específicas e pode continuar sendo utilizado quando ainda é adequado ao processo.

FHIR não deve ser tratado como substituto universal. Em muitos projetos, ele funciona como uma nova camada de interoperabilidade enquanto padrões anteriores permanecem ativos em outras integrações.

Um hospital pode, por exemplo, receber resultados laboratoriais por mensagens HL7 V2 e utilizar recursos FHIR para disponibilizar parte dessas informações a um aplicativo autorizado. As duas abordagens podem coexistir na mesma arquitetura.

A escolha não deve ser feita apenas pela idade do padrão. É necessário considerar o processo atendido, os sistemas envolvidos e a especificação exigida por quem receberá a informação.

Quando padrões diferentes precisam coexistir

O HL7 V2 permanece presente em hospitais porque muitos equipamentos e sistemas utilizam mensagens baseadas nesse padrão. Substituir todas essas interfaces ao mesmo tempo pode gerar custos sem produzir um benefício proporcional.

O DICOM, por sua vez, continua sendo a principal referência para imagens médicas e informações associadas. O FHIR pode representar dados sobre um estudo de imagem ou permitir a localização de determinados registros, mas não assume todas as funções do DICOM.

No relacionamento entre prestadores e operadoras, o padrão TISS atende requisitos definidos pela Agência Nacional de Saúde Suplementar (ANS). Uma API FHIR não substitui a mensagem exigida em um fluxo regulado apenas por utilizar uma tecnologia mais moderna.

Isso significa que o hospital pode usar recursos FHIR internamente e ainda precisar gerar a estrutura TISS prevista para o faturamento. A conformidade depende do padrão exigido no destino, não da preferência tecnológica da instituição.

A coexistência também ocorre durante a modernização de ambientes legados. Uma camada de integração pode receber uma mensagem HL7 V2, transformar os dados necessários e disponibilizá-los como recursos FHIR para novas aplicações.

Essa estratégia preserva investimentos existentes enquanto permite a evolução gradual da arquitetura. Entretanto, toda conversão deve ser validada para evitar perda de contexto ou associação incorreta entre informações.

É necessário substituir os sistemas legados?

Nem sempre. A decisão depende da capacidade do sistema atual de produzir ou fornecer os dados necessários com qualidade suficiente.

Existem três caminhos principais:

Suporte nativo: o próprio sistema disponibiliza recursos e operações FHIR.

Middleware de integração: uma plataforma converte e encaminha informações entre padrões diferentes.

Fachada FHIR: uma camada apresenta dados do sistema legado por meio de interfaces compatíveis.

A integração nativa tende a reduzir componentes intermediários, mas não garante que todos os recursos necessários estejam implementados. O middleware oferece flexibilidade, embora acrescente uma solução que também precisará ser mantida.

Já a fachada FHIR pode ser útil quando o sistema legado armazena informações relevantes, mas não oferece APIs modernas. Nesse caso, a camada externa traduz as consultas e respostas sem modificar toda a aplicação original.

Antes de substituir um sistema, o gestor deve comparar o custo da mudança com o risco de manter a arquitetura existente. Devem ser considerados contratos vigentes, dependências operacionais e capacidade de suporte do fornecedor.

O objetivo não é tornar toda a infraestrutura “FHIR nativa” apenas para acompanhar uma tendência. O projeto deve permitir que os dados necessários circulem com segurança e sejam interpretados corretamente nos processos prioritários do hospital.

Com essa visão, o gestor pode sair da discussão abstrata sobre padrões e avançar para uma decisão prática: como iniciar a adoção sem ampliar o risco da operação?

Como o gestor deve planejar a adoção do HL7 FHIR?

Um projeto de HL7 FHIR deve começar por uma necessidade assistencial ou operacional claramente definida. Quando a instituição inicia pela tecnologia, corre o risco de criar interfaces que funcionam tecnicamente, mas não resolvem um problema relevante.

Antes de contratar uma plataforma ou solicitar alterações ao fornecedor, o gestor precisa identificar onde a informação está interrompendo o fluxo. O problema pode aparecer na redigitação de resultados, na demora para consultar o histórico ou na dificuldade de integrar uma nova aplicação.

O caso de uso orienta todas as decisões posteriores. Ele determina quais dados serão compartilhados, quais sistemas participarão e como o resultado será medido.

Comece por um caso de uso, não pela tecnologia

O primeiro passo é descrever o processo atual. A instituição deve registrar onde a informação é produzida, quem a utiliza e quais intervenções manuais são necessárias para que ela chegue ao destino.

Imagine que o hospital deseje integrar resultados de exames ao prontuário. O projeto precisa identificar o Sistema de Informação Laboratorial (LIS) de origem, os dados obrigatórios e como o PEP apresentará o resultado para a equipe assistencial.

A análise inicial deve responder a cinco perguntas:

Qual problema precisa ser resolvido?

Que informação deverá circular?

Quais sistemas estão envolvidos?

Quem poderá acessar os dados?

Como o hospital reconhecerá que o processo melhorou?

Depois disso, a equipe pode selecionar um piloto. O ideal é escolher um fluxo relevante, mas com escopo controlável e responsáveis claramente identificados.

O piloto deve passar por um ambiente de homologação antes de entrar em produção. Nesse período, a instituição verifica se os recursos estão estruturados corretamente e se as informações chegam ao paciente certo.

Os testes não podem se limitar ao cenário ideal. Também é necessário avaliar o comportamento quando um campo obrigatório está ausente, a identificação do paciente é divergente ou o sistema receptor está indisponível.

Uma integração segura precisa saber tratar a falha, não apenas concluir a operação quando todos os dados estão corretos.

Após a validação, a implantação pode ocorrer gradualmente. O aprendizado do primeiro caso de uso ajuda a aperfeiçoar os critérios para as próximas integrações.

O que cobrar do sistema e do fornecedor

A expressão “compatível com HL7 FHIR” pode descrever capacidades muito diferentes. Um fornecedor pode suportar apenas alguns recursos ou oferecer uma interface que ainda depende de desenvolvimento adicional para cada cliente.

Por isso, a avaliação deve solicitar respostas verificáveis. Não basta receber uma confirmação comercial; é preciso compreender o escopo do suporte oferecido.

Também é importante verificar se a integração é nativa ou depende de uma empresa intermediária. Caso exista middleware, o contrato deve indicar quem será responsável por configurar e monitorar esse componente.

Os custos precisam ser apresentados de forma completa. Além da licença, podem existir despesas com desenvolvimento, infraestrutura e atualizações futuras. A instituição também deve considerar o esforço das equipes internas durante o mapeamento e a homologação.

O contrato deve esclarecer a portabilidade das informações. O hospital não pode depender de uma integração que dificulte o acesso aos próprios dados quando houver troca de fornecedor.

Outro ponto é a observabilidade. O sistema deve permitir identificar mensagens rejeitadas e tempo de resposta, além da causa de cada falha. Sem essa visibilidade, a equipe descobre o problema somente quando o usuário reclama que a informação não chegou.

Como medir se a integração funcionou

A conclusão técnica do projeto não comprova que o processo melhorou. Para medir o resultado, o hospital precisa registrar uma linha de base antes da implantação.

Se o objetivo for reduzir redigitação, por exemplo, a instituição deve medir quantos resultados exigiam intervenção manual e quanto tempo a equipe gastava nessa atividade. Depois, os mesmos indicadores podem ser acompanhados no processo integrado.

Os indicadores técnicos devem ser associados a um resultado operacional. Uma API pode apresentar alta disponibilidade e, ainda assim, não reduzir o trabalho da equipe se o dado chegar em um formato inadequado para o fluxo.

A instituição também precisa monitorar a identificação do paciente. Uma baixa taxa de erro técnico perde importância se os registros forem vinculados à pessoa errada ou permanecerem sem associação.

O sucesso da adoção deve ser demonstrado no processo hospitalar, não apenas no painel da tecnologia. Quando a informação chega corretamente e no momento necessário, o padrão começa a produzir valor para a gestão e para o cuidado.