De tempos em tempos volta a circular a mesma infografia: dois hospitais nas laterais, um barramento de integração no centro, algumas setas indo e vindo e, por cima de tudo, o logotipo do HL7 FHIR como selo de garantia. A mensagem implícita é simples: instale isto e seus sistemas vão interoperar.
Participei de guias de implementação FHIR nacionais e regionais. Justamente por isso posso dizer sem rodeios: essa infografia não descreve uma arquitetura de interoperabilidade. Descreve, na melhor das hipóteses, uma tubulação.
Vamos colocá-la à prova com um caso cotidiano. Uma mulher de 67 anos com insuficiência cardíaca, atendida durante anos em um hospital privado, chega às duas da manhã ao pronto-socorro de um hospital público. O médico de plantão precisa do resumo clínico dela: diagnósticos, medicamentos, alergias. Tem cinco minutos.
No hospital privado ela está registrada com o número do documento de identidade. No público, com um número de prontuário e o sobrenome escrito errado. Quem decide que são a mesma pessoa? Ninguém no hospital público sabe que existe um resumo no privado, nem em que serviço ele está disponível.
Quando a consulta chegar, o hospital privado precisará saber quem a faz, se é um profissional habilitado, de qual organização e com que finalidade. Precisará saber se ela autorizou compartilhar suas informações e quem avalia essa autorização. A furosemida dela terá de significar o mesmo nos dois sistemas. E amanhã alguém precisará poder demonstrar quem viu o quê, quando e por quê.
As setas da infografia não respondem a nenhuma dessas perguntas. E nenhuma se resolve escolhendo o recurso FHIR certo.
O que o FHIR é
Convém ser preciso, porque a crítica fácil também é fumaça. O FHIR não é "só sintaxe". Define recursos com semântica clínica, interações REST, mensageria e documentos. Também define mecanismos de conformidade, vínculos com terminologias e até recursos para consentimento, proveniência e auditoria. É provavelmente o avanço mais importante em padrões de saúde das últimas duas décadas.
Mas a própria especificação é clara sobre seu alcance. Na seção de perfilamento, a HL7 descreve o FHIR como uma especificação de plataforma. É uma base comum sobre a qual se constroem soluções distintas, e normalmente precisa ser adaptada a cada contexto de uso por meio de perfis e guias de implementação. Na seção de segurança, adverte que o FHIR não é um protocolo de segurança e que depende de mecanismos definidos em outros lugares.
Essa distinção tem consequências práticas:
- O FHIR define o recurso
Consent, mas não decide qual política de consentimento se aplica em um país nem implementa o motor que a faz cumprir. - Define
AuditEvent, mas não garante que alguém audite, nem define por quanto tempo o registro é mantido ou quem o revisa. - Define
Patient, mas não decide qual é o identificador oficial nem como os duplicados são resolvidos.
Por isso dizer que um sistema "suporta FHIR" diz muito pouco. A conformidade é sempre contra algo: um guia de implementação, um conjunto de perfis, uma versão, um CapabilityStatement. Afirmar que um sistema é interoperável porque "fala FHIR" se parece com afirmar que um contrato é válido porque está escrito em português.
O que o desenho não responde
Voltemos ao pronto-socorro. Cada pergunta do caso corresponde a uma capacidade que alguém precisa projetar, operar e governar.
Identidade. Antes de pedir qualquer dado, ambos os hospitais precisam saber que estão falando da mesma pessoa. Isso exige um índice mestre de pacientes e regras de correlação. Exige também uma política sobre qual identificador prevalece e um procedimento para quando o algoritmo erra.
Descoberta. O hospital público precisa saber quais organizações participam, quais profissionais trabalham nelas e onde estão seus serviços. Isso é um diretório, com regras sobre quem o mantém e como é atualizado.
Intercâmbio. O resumo precisa ser publicado, encontrado e recuperado. Aqui o FHIR faz o trabalho pesado, mas dentro de um contrato que diz exatamente quem envia o quê a quem.
Conteúdo. De nada serve o documento chegar se não for compreendido. O resumo precisa de uma estrutura acordada, como o International Patient Summary e um guia nacional que o adapte. Precisa também de terminologias vinculadas: SNOMED CT, LOINC, um catálogo de medicamentos. É a parte mais "FHIR" do problema e, ainda assim, exige governança: quem mantém os conjuntos de valores, qual terminologia é oficial, quem paga as licenças.
Acesso e consentimento. O hospital privado precisa verificar quem consulta, com qual direito e se a paciente autorizou compartilhar. Os perfis tornam executável essa política, mas nenhum a escreve.
Rastreabilidade. Cada acesso deve ficar registrado de forma verificável. Para que uma auditoria tenha valor, todos os sistemas devem concordar quanto à hora. Até o relógio precisa ser governado.
O IHE especificou cada uma dessas capacidades como perfis com atores e transações concretos:
| Pergunta do caso | Capacidade | Perfil IHE / guia HL7 |
|---|---|---|
| É a mesma pessoa? | Identidade | PIXm, PDQm; PMIR para gerenciá-la na comunidade |
| Quem é quem e onde está o serviço? | Diretório | mCSD |
| Onde está o resumo e como o obtenho? | Intercâmbio de documentos | MHD (ITI-65, ITI-67, ITI-68) |
| O conteúdo significa o mesmo? | Conteúdo e terminologia | IPS + guia nacional; SVCM |
| Quem pede e com qual direito? | Autorização | IUA (OAuth 2.0); SMART App Launch |
| A paciente autorizou? | Consentimento | PCF |
| Fica um rastro verificável? | Auditoria | ATNA, BALP |
| Os relógios coincidem? | Tempo consistente | CT |
Há um dado que resume o argumento melhor que qualquer opinião. O IHE publicou o MHDS, um perfil cujo propósito é descrever os serviços mínimos de uma comunidade de intercâmbio de documentos baseada em FHIR. O MHDS não inventa um padrão novo: agrupa o MHD com identidade, diretório, auditoria e tempo consistente, entre outros. Se um servidor FHIR bastasse para intercambiar documentos entre instituições, esse perfil não teria razão de existir.
Nem todos esses perfis são obrigatórios em todos os projetos. O que eles demonstram é que cada capacidade tem atores, transações e responsabilidades que não aparecem só por instalar um servidor.
Nem o IHE é a arquitetura
Seria fácil transformar este artigo em "FHIR contra IHE", mas seria outra simplificação. Os perfis IHE são contratos de integração reutilizáveis, e muitos são construídos sobre o FHIR. O que um contrato não decide são as perguntas que vêm antes:
- O índice de pacientes será central ou federado, e quem o opera?
- Com qual base legal se compartilham informações sem consentimento em uma emergência?
- Qual organização certifica os participantes?
- Quem responde quando um dado está incorreto?
Os marcos que melhor funcionam no mundo começam justamente por aí. O OpenHIE constrói sua arquitetura a partir de fluxos de trabalho. Atribui-os a componentes compartilhados e depois os mapeia para perfis IHE. Esses componentes incluem os registros de clientes, de estabelecimentos e de trabalhadores de saúde, a terminologia, o registro clínico compartilhado e a camada de interoperabilidade.
As SMART Guidelines da OMS colocam os Digital Adaptation Kits em uma camada anterior ao guia FHIR. Esses kits contêm personas, processos de negócio, dicionário de dados e lógica de decisão. Primeiro o processo; depois o padrão.
Os Estados Unidos oferecem o exemplo mais eloquente. É o país que tornou obrigatórias por regulação as APIs FHIR na tecnologia de saúde certificada. Ainda assim, para interoperar em escala nacional precisou do TEFCA. O TEFCA combina um marco de confiança, um acordo comum assinado pelos participantes e redes designadas (QHIN) com obrigações explícitas. A troca entre essas redes se apoia em grande medida em perfis IHE. O país com mais FHIR implantado no mundo não resolveu a interoperabilidade só com FHIR: resolveu com governança.
O marco europeu refinado de interoperabilidade em saúde (ReEIF) o expressa em seis camadas: legal e regulatória, política, processo assistencial, informação, aplicações e infraestrutura. O FHIR ocupa, no máximo, duas delas. As outras quatro não se compram; são projetadas e acordadas.
O custo do atalho
Confundir uma plataforma com uma arquitetura não é um erro teórico. Tem custos que aparecem dois ou três anos depois da compra, quando já é caro corrigi-los.
A dependência do fornecedor. Um servidor FHIR sem guia de implementação nacional se enche de extensões próprias. Os dados ficam em FHIR, mas em um FHIR que só aquele produto entende.
As integrações ponto a ponto disfarçadas. Um barramento que conecta cada instituição com regras de transformação particulares não elimina a complexidade: a esconde. Cada novo participante é um projeto novo, e a solução não pode ser reproduzida em outra região nem com outro fornecedor.
A segurança acrescentada no final. Quando autorização, consentimento e auditoria não foram projetados desde o início, são acrescentados como remendos, ou simplesmente não são acrescentados. O risco recai sobre as instituições e os pacientes, não sobre quem vendeu a plataforma.
O repositório central que copia tudo. Sem identidade, diretório nem localização de documentos, a saída mais rápida costuma ser centralizar cópias dos dados de todos. Funciona na demonstração e complica todo o resto: a responsabilidade sobre o dado, a sincronização, a privacidade e a confiança das instituições que devem entregar suas informações.
Nada pode ser verificado. Este é talvez o custo mais grave. Sem perfis declarados nem testes de conformidade, ninguém pode demonstrar que dois sistemas interoperam corretamente. Só resta confiar na apresentação.
Antes de comprar, pergunte
Uma solução pode ser totalmente compatível com o HL7 FHIR e, ainda assim, ser insuficiente para o caso para o qual foi adquirida. Por isso as instituições deveriam avaliar as propostas pelas capacidades que demonstram, não pela lista de tecnologias que mencionam. Estas perguntas ajudam a separar uma arquitetura de uma apresentação:
- Contra quais guias de implementação e perfis declara conformidade, e em qual versão do FHIR? "Suportamos FHIR" não é uma resposta.
- Publica seu
CapabilityStatement? - Quais atores IHE implementa e quais transações cada um suporta?
- Que evidência de testes tem: Connectathon, Gazelle, Inferno, validadores do guia nacional?
- Como se resolve a identidade do paciente e quem governa o índice mestre?
- Onde se avalia o consentimento e onde fica registrada a auditoria?
- Quais extensões proprietárias utiliza e como os dados são exportados se trocar de fornecedor?
Se as respostas forem vagas, o problema não é técnico. É que não há arquitetura por trás.
Primeiro a arquitetura, depois a tecnologia
A paciente do pronto-socorro não precisa de um servidor FHIR. Precisa que seu médico veja, em cinco minutos, a informação correta da pessoa correta. Precisa que isso aconteça com a autorização dela ou com a base legal que a substitua, e que fique registro. Consegui-lo exige decidir processos, papéis, responsabilidades, serviços compartilhados e regras de confiança. O FHIR é indispensável para isso, mas não é suficiente.
As instituições que começam pelo processo acabam escolhendo melhor a tecnologia. As que começam pela tecnologia costumam descobrir o processo quando já assinaram o contrato.
O FHIR nos dá uma linguagem comum para trocar informações de saúde. A arquitetura determina quem pode utilizá-la, para quê, sob quais condições e como essa troca se converte em um processo de saúde interoperável. Não confundamos falar a mesma língua com saber trabalhar juntos.
Referências
- HL7 FHIR R5, Profiling FHIR
- HL7 FHIR R5, Security
- IHE IT Infrastructure: perfis MHD, MHDS, mCSD, PIXm, PDQm, PMIR, IUA, PCF, BALP, SVCM e CT
- OpenHIE, Architecture Specification
- Organização Mundial da Saúde, SMART Guidelines
- eHealth Network, Refined eHealth European Interoperability Framework (ReEIF)
- ONC/ASTP (EUA), Trusted Exchange Framework and Common Agreement (TEFCA)
Boletim da Meddyg
Notícias, novidades de interoperabilidade e saúde digital, e o que há de novo em nossos serviços e produtos.