As quatro camadas da interoperabilidade em saúde e por que a última é a que falha

Existe uma assimetria persistente entre o discurso sobre interoperabilidade em saúde e o que se observa na operação. No discurso, o problema é apresentado como técnico e, portanto, solúvel por adoção de padrões: bastaria que os sistemas falassem HL7, expusessem recursos FHIR e respeitassem DICOM para que a informação circulasse. Na operação, organizações que adotaram todos esses padrões continuam convivendo com exames que não encontram seu registro, laudos que não retornam e cadastros duplicados.

A explicação para essa assimetria não é que os padrões falhem naquilo a que se propõem. É que interoperabilidade não é uma propriedade única, e sim um conjunto de camadas com naturezas distintas — algumas técnicas, outras não. Adotar um padrão resolve integralmente a camada mais baixa e apenas parcialmente as demais.

A distinção em camadas não é original nem controversa: variações dela aparecem em quadros de referência de saúde digital há mais de duas décadas, tipicamente separando os planos técnico, sintático, semântico e organizacional. O que se propõe aqui é examinar por que a distribuição do esforço entre essas camadas costuma ser inversa à distribuição das falhas.

1. Camada técnica: o transporte

A camada técnica trata da conectividade: existe rota entre os sistemas, as portas estão abertas, o certificado é válido, a rede comporta o volume. É a camada mais elementar e também a mais bem resolvida, porque suas falhas são binárias e imediatamente visíveis. Quando o transporte não funciona, ninguém discute se funciona.

Vale registrar que ela não é trivial em ambientes de imagem. O crescimento no tamanho dos estudos — mais cortes, mais séries, maior profundidade de bits — impõe pressão sobre armazenamento e largura de banda que não acompanha a percepção de quem dimensionou o ambiente anos antes. Ainda assim, a falha aqui é diagnosticável com instrumentos convencionais e raramente sobrevive a uma investigação séria.

2. Camada sintática: o formato

A camada sintática trata da estrutura da mensagem: o receptor consegue analisar o que recebeu. É onde os padrões atuam de forma mais direta e onde a conformidade é mais facilmente verificável. Uma mensagem HL7 v2 malformada é rejeitada; um objeto DICOM sem os atributos obrigatórios de um módulo é recusado pelo servidor.

Convém notar, porém, que a conformidade sintática admite graus. O HL7 v2 é notório por sua flexibilidade: segmentos opcionais, campos definidos localmente e a prática difundida de usar segmentos Z para extensões proprietárias fazem com que duas implementações igualmente conformes possam ser mutuamente incompreensíveis. O DICOM enfrenta questão análoga, mitigada pela figura da declaração de conformidade, que documenta o que cada implementação de fato suporta — documento que, na prática institucional, raramente é lido antes da compra.

A consequência é que a conformidade sintática é condição necessária e claramente insuficiente. Dois sistemas conformes trocam mensagens analisáveis; nada garante que extraiam delas o mesmo conteúdo.

3. Camada semântica: o significado

A camada semântica é onde a discussão deixa de ser sobre formato e passa a ser sobre sentido. Ela pergunta se o dado recebido significa, para quem recebe, o mesmo que significava para quem enviou.

É aqui que entram as terminologias e classificações clínicas — SNOMED CT, LOINC, CID — cuja função é justamente ancorar termos em conceitos estáveis e compartilhados. Sem essa ancoragem, um campo de texto livre com o nome de um procedimento é, para efeito computacional, apenas uma sequência de caracteres: comparável por igualdade, não por significado.

A dificuldade prática é que a adoção de terminologias impõe custo no momento do cadastro e devolve benefício apenas depois, quando alguém tenta agregar ou comparar. Como o custo é imediato e visível enquanto o benefício é diferido e difuso, a decisão institucional tende sistematicamente ao adiamento. O resultado é um acervo internamente coerente e externamente incomparável — o que só se descobre quando surge a necessidade de integrar com um segundo sistema, participar de uma rede ou responder a uma exigência regulatória.

A ausência de terminologia não impede a operação diária. Ela impede que os dados de hoje respondam às perguntas de amanhã.

4. Camada organizacional: o acordo

A quarta camada é a que menos se parece com um problema de tecnologia e é, com folga, a que mais frequentemente determina o insucesso de um projeto de integração. Ela trata das condições sob as quais duas organizações concordam em trocar informação: qual identificador de paciente prevalece, quem é responsável pela qualidade do que envia, o que acontece quando os cadastros divergem, quem responde por um incidente que atravessa a fronteira entre os dois sistemas.

Nenhuma dessas perguntas tem resposta técnica. A escolha do identificador que prevalece é política antes de ser arquitetural; a responsabilidade pela qualidade do dado é contratual; a divergência de cadastro exige um processo humano de conciliação que nenhum algoritmo resolve sozinho, porque envolve decidir qual dos dois registros descreve corretamente uma pessoa real.

A literatura de saúde digital reconhece essa camada há tempos, e é sintomático que as iniciativas mais bem-sucedidas de interoperabilidade em escala tenham dedicado esforço desproporcional a ela — definindo perfis de uso, acordos de participação e papéis institucionais antes de discutir mensageria. Ainda assim, no projeto típico de uma clínica ou hospital, a camada organizacional costuma ser tratada como formalidade posterior à escolha técnica, quando deveria precedê-la.

A inversão entre esforço e falha

Reunindo as quatro camadas, emerge um padrão que explica a assimetria inicial. O esforço de um projeto de integração concentra-se nas camadas baixas, onde o trabalho é mensurável, atribuível a uma equipe técnica e demonstrável em uma reunião de status. As falhas, contudo, concentram-se nas camadas altas, onde o trabalho é difuso, exige decisão institucional e não produz artefato exibível.

Essa inversão tem uma consequência prática frequentemente ignorada: um projeto pode ser declarado tecnicamente concluído e operacionalmente inútil. As mensagens trafegam, os sistemas respondem, os testes de conformidade passam — e a recepção continua ligando para perguntar por que o exame não aparece, porque o identificador diverge e ninguém decidiu qual prevalece.

Sobre a promessa do FHIR

Uma ressalva é devida a respeito das expectativas depositadas em padrões mais recentes. O FHIR representa um avanço real de engenharia: modelo de recursos mais claro, uso de tecnologias web correntes, curva de aprendizado menor. Nada disso é pouco.

Mas convém observar que os ganhos se concentram, novamente, nas camadas técnica e sintática. O FHIR facilita expor e consumir recursos; não decide qual identificador prevalece entre duas instituições, não obriga ninguém a usar terminologia padronizada, e não estabelece quem responde pela qualidade do dado. Sua extensibilidade — virtude do ponto de vista da adoção — reintroduz, por outro caminho, a mesma variabilidade que tornou o HL7 v2 difícil de generalizar.

A conclusão razoável não é que o padrão seja insuficiente, e sim que se está exigindo dele algo que padrão nenhum entrega. Especificações técnicas descrevem como trocar informação. Elas não substituem o acordo sobre o que a informação significa nem sobre quem responde por ela.

Consequências para a condução de projetos

Se o diagnóstico acima procede, três reordenações se impõem à forma como projetos de integração em saúde são conduzidos.

A primeira é cronológica: as decisões da camada organizacional deveriam anteceder a escolha de arquitetura, e não sucedê-la. Definir identificador prevalente, responsabilidade sobre qualidade e processo de conciliação antes de especificar mensageria evita retrabalho que, descoberto tarde, costuma ser caro.

A segunda é sobre o critério de conclusão. Um projeto de integração não deveria ser considerado entregue quando as mensagens trafegam, e sim quando o fluxo se completa do ponto de vista de quem opera — o que, em imagem, significa incluir explicitamente o caminho de retorno do laudo, historicamente menos monitorado que o de ida.

A terceira diz respeito à avaliação de fornecedores. A pergunta útil não é se o sistema é compatível com determinado padrão, formulação que quase sempre recebe resposta afirmativa, mas quais recursos específicos são suportados, em qual versão, com qual documentação — informação que a declaração de conformidade existe precisamente para registrar.

Nenhuma dessas reordenações é tecnicamente difícil. Todas exigem que a conversa comece em um lugar diferente daquele em que costuma começar, o que é uma dificuldade de outra natureza.