Se você trabalha com tecnologia há algum tempo, provavelmente já ouviu falar de sistemas que deveriam “conversar” entre si e simplesmente não conversam. No mercado de saúde, esse problema tem um nome e uma história razoavelmente longa — e é o ponto de partida deste guia.
O problema que o FHIR resolve: silos de dados em saúde
Imagine o histórico clínico de um único paciente: exames feitos em um laboratório, prescrições emitidas por uma clínica, internações registradas em um hospital, resultados de imagem armazenados em outro sistema ainda. Cada um desses pontos normalmente é operado por um software diferente, de um fornecedor diferente, com um modelo de dados diferente. O resultado é previsível: a informação existe, mas fica presa em compartimentos que não se comunicam — os chamados silos de dados.
Isso não é apenas um incômodo técnico. Um médico que não tem acesso ao histórico completo de um paciente pode duplicar exames, prescrever uma medicação que interage mal com outra já em uso, ou simplesmente perder tempo precioso reconstruindo informações que já existiam em algum lugar. Resolver esse problema — permitir que sistemas de saúde diferentes troquem dados de forma confiável e padronizada — é o que se chama de interoperabilidade em saúde, e é o problema central que o FHIR foi desenhado para enfrentar.
Uma linha do tempo curta: de HL7 v2 ao FHIR
O FHIR não nasceu no vácuo. Ele é a evolução mais recente de um esforço de padronização que a HL7 (Health Level Seven International) conduz desde a década de 1980.
- HL7 v2, criado ainda nos anos 1980, é um padrão de mensageria amplamente adotado até hoje, especialmente para eventos como admissão, alta e transferência de pacientes (os famosos “eventos ADT”). Sua sintaxe própria, baseada em segmentos separados por delimitadores, funciona bem, mas é pouco amigável para quem vem do mundo de APIs modernas.
- HL7 v3 tentou resolver as limitações do v2 com um modelo de informação mais rigoroso e formal (o RIM — Reference Information Model), mas sua complexidade tornou a adoção mais lenta do que o esperado.
- CDA (Clinical Document Architecture), derivado do v3, padronizou documentos clínicos completos (como sumários de alta), mas manteve o foco em documentos, não em dados granulares e consultáveis.
O FHIR (Fast Healthcare Interoperability Resources), publicado pela HL7, surge como resposta a essas limitações: em vez de mensagens rígidas ou documentos monolíticos, ele propõe unidades de dados menores e reutilizáveis — os recursos — expostas através de uma API REST, no mesmo estilo que qualquer desenvolvedor web já conhece de outros contextos. A especificação completa está disponível publicamente em hl7.org/fhir, e é a referência que este guia vai usar do início ao fim.
O que é um “recurso” FHIR, em linhas gerais
Sem entrar em detalhes técnicos ainda — isso fica para os artigos 3 e 5 deste guia — vale adiantar a ideia central: no FHIR, cada tipo de informação em saúde (um paciente, uma consulta, um exame, uma prescrição) é modelado como um recurso. Um recurso é uma estrutura de dados com um formato bem definido, um identificador único e um conjunto de elementos que descrevem aquele conceito clínico ou administrativo. Um recurso Patient descreve um paciente; um recurso Observation descreve uma observação clínica, como um resultado de exame.
Essa abordagem modular é o que permite ao FHIR ser, ao mesmo tempo, simples de entender e flexível o suficiente para cobrir praticamente qualquer cenário de saúde — dos mais comuns aos mais específicos de um país ou de uma organização.
Por que uma API REST?
Outra decisão de design central do FHIR foi expor esses recursos através de uma API REST — o mesmo padrão arquitetural usado por boa parte da web moderna, com verbos HTTP (GET, POST, PUT, DELETE) operando sobre URLs previsíveis. Essa escolha não é incidental: ela reduz drasticamente a barreira de entrada para desenvolvedores que já têm familiaridade com REST, elimina a necessidade de ferramentas ou protocolos proprietários para consumir dados de saúde, e aproxima o mundo da saúde das práticas já consolidadas no desenvolvimento de software em geral. Um desenvolvedor que nunca trabalhou com dados clínicos consegue, em poucos minutos, entender que GET /Patient/123 busca o paciente de identificador 123 — mesmo sem saber ainda o que cada campo daquele recurso significa clinicamente.
Quem usa FHIR hoje
A adoção do FHIR deixou de ser uma aposta de early adopters há alguns anos. Ele é hoje a base de:
- Grandes prontuários eletrônicos (EHRs) usados amplamente em hospitais e redes de saúde ao redor do mundo;
- Iniciativas regulatórias, como as exigências de acesso a dados de pacientes nos Estados Unidos, apoiadas em APIs FHIR;
- Serviços gerenciados de nuvem (assunto que este guia retoma em detalhe mais adiante, nos artigos sobre Google Cloud Healthcare API e AWS HealthLake);
- Iniciativas nacionais de interoperabilidade em saúde — incluindo, como veremos a seguir, o caso brasileiro.
O caso brasileiro: a RNDS
Um dos exemplos mais concretos e relevantes de adoção do FHIR no Brasil é a Rede Nacional de Dados em Saúde (RNDS), estruturada pelo Ministério da Saúde. A RNDS foi concebida justamente para resolver, em escala nacional, o mesmo problema que abre este artigo: laudos, resultados de exame e outros registros de saúde que, sem uma rede de interoperabilidade, ficam restritos ao sistema do estabelecimento que os produziu — inacessíveis a outros pontos de atendimento e, muitas vezes, ao próprio paciente.
O marco regulatório da RNDS é a Portaria nº 1.792, de 17 de julho de 2020, do Ministério da Saúde — um divisor de águas para a interoperabilidade em saúde no país. O primeiro caso de uso real que motivou e validou a arquitetura da rede foi a notificação de resultados de exames de SARS-CoV-2: laboratórios de análises clínicas passaram a enviar esses resultados à RNDS seguindo o padrão FHIR, através de um software de integração — chamado de “conector” — desenvolvido por cada estabelecimento de saúde.
A partir desse primeiro caso de uso, a RNDS foi estendida para cobrir outros cenários, como o Registro de Atendimento Clínico (RAC) e o Sumário de Alta (SA), sempre seguindo a mesma lógica: cada estabelecimento se integra à rede por meio de requisições HTTPS que obedecem ao padrão FHIR e às adaptações específicas definidas pela RNDS, documentadas no Guia de Integração RNDS e no Implementation Guide técnico, ambos publicados oficialmente pelo Ministério da Saúde. Esse é um ponto que vamos retomar com mais profundidade ao longo do guia, especialmente no artigo 4 (sobre CodeSystems) e no artigo de encerramento, dedicado inteiramente ao uso do FHIR no Brasil.
Por que este guia existe
Este é o primeiro de uma série de artigos pensada para ambientar engenheiros de software — e qualquer profissional de tecnologia curioso sobre o tema — no padrão FHIR, partindo do conceitual e avançando progressivamente para o técnico. Os próximos artigos vão cobrir, nessa ordem, como o FHIR consegue ser compreendido por públicos técnicos e não técnicos, os formatos de dados suportados, terminologias e CodeSystems, o catálogo de recursos, extensões e profiling, as operações REST do dia a dia, versionamento, segurança, auditoria, estratégias de persistência, os principais serviços gerenciados de nuvem, a evolução das versões da especificação, o recurso de consentimento e, por fim, um panorama consolidado do uso do FHIR no Brasil.
A ideia não é substituir a especificação oficial — que continua sendo a referência definitiva sobre o assunto —, mas oferecer um caminho guiado por ela, com contexto e exemplos práticos, para quem está começando agora.