Interoperabilidade domiciliar: RNDS, e-SUS e integração

Interoperabilidade na atenção domiciliar é a capacidade de trocar informações e preservá-las utilizáveis no processo de destino. Ter uma API, exportar uma planilha ou produzir um arquivo padronizado pode fazer parte do caminho. Nenhum desses elementos, isoladamente, comprova que a equipe destinatária recebeu a informação correta, vinculada à pessoa certa e com o significado esperado.

Para uma Secretaria de Saúde, um prestador ou uma operadora, a pergunta de contratação precisa ser concreta: qual informação sairá de qual sistema, para qual finalidade, por qual fluxo e com qual evidência de recebimento? “Integra com o SUS” é uma resposta ampla demais para sustentar um projeto.

Este guia trata do desenho e da avaliação de integrações. Não declara que a HAI já integra com RNDS, e-SUS APS ou qualquer prontuário específico. Disponibilidade, credenciamento, modelos, versões e escopo devem ser demonstrados em cada implantação.

Integração não é um item que se marca como concluído e abandona. A liderança precisa definir responsáveis por dados, exceções e manutenção. Sem essa definição, a tecnologia apenas transporta uma desorganização que continua sendo da instituição.

RNDS, e-SUS APS e prontuário não são a mesma coisa

A RNDS é apresentada pelo Ministério da Saúde como a plataforma nacional de interoperabilidade para compartilhamento de informações de saúde. Seu guia técnico reúne modelos e orientações de integração. Isso não significa que qualquer documento local possa ser enviado sem correspondência com um modelo disponível.

O guia de implementação da RNDS orienta consultar as regras gerais junto ao guia específico do modelo escolhido, baseado em FHIR R4. A expressão “usa FHIR” não comprova atendimento a todos esses requisitos. É preciso dizer qual modelo, qual versão e quais operações estão implementadas.

O e-SUS APS pertence a outro recorte da organização da informação. A documentação de integração e-SUS APS apresenta o LEDI APS para integração de sistemas próprios com o PEC. Um fluxo para e-SUS APS não deve ser confundido automaticamente com um fluxo direto para RNDS. O destino e o objetivo de cada envio precisam estar descritos.

Também há informação que permanece no prontuário ou na gestão local do serviço. Um plano operacional de visitas, uma confirmação logística e um registro clínico têm finalidades distintas. O projeto deve identificar quais dados são pertinentes a cada fluxo, em vez de tentar transportar toda a base para todos os destinos.

Comece pelo uso da informação

Antes de discutir endpoints e formatos, descreva o que o destinatário precisa fazer. Consultar um histórico para continuidade do cuidado, registrar produção em um fluxo oficial e conferir uma conta são problemas diferentes. Misturar essas finalidades cria contratos de integração imprecisos.

Uma proposta de especificação deve responder: qual evento inicia o envio; quais campos são necessários; qual sistema é responsável pela origem; qual confirmação será aceita; como erros aparecem; e quem acompanha a correção. A definição deve ser compreensível para a área de negócio e para a TI.

Se ninguém consegue explicar o processo sem dizer “a API resolve”, falta trabalho de desenho. A API transporta o que foi definido. Ela não decide sozinha se a informação está completa, se o registro se refere ao atendimento certo ou se a equipe entende o que recebeu.

Identidade, significado e tempo precisam viajar juntos

Uma integração pode transportar valores corretos e associá-los ao episódio errado. Pode enviar uma atualização como novo registro e criar duplicidade. Pode substituir uma informação mais recente por outra recebida com atraso. Esses são exemplos de riscos que o roteiro de avaliação precisa contemplar, não uma descrição de falhas de um produto específico.

Por isso, proponha uma matriz que relacione pessoa, atendimento, unidade, profissional, evento e versão conforme a necessidade do fluxo. A regra de identificação deve ser explícita e compatível com as exigências do destino. Divergências de cadastro precisam de tratamento, não de correspondência aproximada aplicada silenciosamente.

O tempo também tem mais de um significado. A hora do atendimento, a hora do registro e a hora do recebimento podem ser diferentes. O sistema deve preservar as distinções relevantes, principalmente em situações de sincronização posterior. O texto sobre aplicativo de visita sem internet aprofunda esse problema no ponto de origem.

Exemplo fictício: enviado não significa concluído

Uma equipe registra uma visita e o sistema informa que a mensagem foi enviada. O destinatário recebe a mensagem, mas rejeita parte do conteúdo por incompatibilidade com o modelo. A equipe assistencial vê “sincronizado”; a gestão considera a produção encerrada; a TI mantém o erro em um log que ninguém acompanha.

O defeito do processo está na tradução entre estados. Sincronizar com a plataforma local não equivale a obter aceite de outro sistema. O usuário precisa entender qual etapa foi concluída e qual ainda exige ação, sem receber mensagens técnicas incompreensíveis.

A correção proposta é definir os estados relevantes e atribuir responsáveis por exceções. O registro original permanece preservado. A pessoa autorizada corrige o que for necessário no fluxo pertinente, e o reenvio deve ser acompanhado para não gerar duplicidade. A conclusão depende da evidência combinada, não de um botão verde no sistema de origem.

Homologação precisa incluir as exceções

O guia de integração da RNDS distingue ambientes de homologação e produção e descreve condições de acesso e evidências do processo. Uma prova realizada em ambiente de testes não deve ser anunciada como integração produtiva de todos os clientes.

Além dos casos previstos pelo destino, a organização deve avaliar cenários relevantes à sua operação: identificador divergente, campo obrigatório ausente, versão incompatível, envio repetido, interrupção de comunicação e atualização de um registro anterior. Esse roteiro é uma proposta de aceite, não uma lista oficial exaustiva.

Cada cenário precisa registrar entrada, resultado esperado, resultado observado e decisão sobre o desvio. Testar somente o caso em que todos os dados estão corretos deixa de fora justamente o trabalho que costuma consumir a equipe depois da implantação.

Integração também exige manutenção

Um contrato deve esclarecer quem acompanha mudanças de versão e quem corrige incompatibilidades. O Ministério da Saúde publicou orientação sobre atualização do e-SUS APS e qualidade dos dados, mostrando que compatibilidade precisa ser sustentada ao longo do tempo. A versão e a regra aplicáveis devem ser reconferidas no projeto.

Não deixe o acompanhamento concentrado em uma pessoa que conhece o caminho de memória. Documente finalidade, responsáveis, dependências, limites e procedimentos para incidentes. Mudança de equipe não pode fazer a organização perder a capacidade de explicar para onde seus dados vão.

A governança de acesso também deve estar no desenho. Compartilhar informações com um sistema não significa liberá-las a todos os seus usuários. Finalidade, necessidade, perfis e rastreabilidade devem ser tratados pelos responsáveis. O guia de compartilhamento e exportação de dados complementa essa discussão.

Como levar essa conversa para a compra da HAI

Na avaliação da HAI para Secretarias de Saúde, leve o mapa dos sistemas existentes e os fluxos que precisam continuar funcionando. Separe o que é gestão do cuidado, o que é registro assistencial e o que é envio oficial. A HAI não deve ser apresentada como substituta automática dos sistemas oficiais.

Peça demonstração do escopo disponível, identificação das dependências e proposta de aceite para as integrações necessárias. Para prestadores e operadoras, o mesmo método se aplica à avaliação da HAI, com os destinos pertinentes à operação.

Interoperabilidade útil é a que sustenta o trabalho depois da demonstração. O projeto só amadurece quando dados, responsabilidades, exceções e manutenção fazem parte da mesma conversa.