RNDS e eSaúde
A RNDS é a plataforma nacional de interoperabilidade do Ministério da Saúde. Os estabelecimentos notificam eventos assistenciais a ela em HL7 FHIR R4, e esses registros passam a compor o histórico de saúde do cidadão.
Na prática, o hospital precisa extrair o evento de dentro do ERP que já usa, traduzi-lo para o formato que a RNDS aceita e entregá-lo autenticado. É esse caminho que a Forti constrói.
A RNDS define os tipos de documento no CodeSystem BRTipoDocumento, publicado no guia FHIR oficial. A Forti cobre os seis:
Documento que fecha o episódio de internação, enviado na alta do paciente.
Notifica o atendimento assistencial prestado ao paciente.
Registra a aplicação de vacinas e demais imunobiológicos.
Notifica a prescrição, ligando o medicamento ao profissional que o prescreveu.
Notifica a entrega efetiva do medicamento ao paciente.
Envia o resultado de exame liberado pelo laboratório.
A RNDS é o destino. O problema real está na origem — em como o evento sai do sistema que o hospital já opera. A Forti implementa a partir dos três:
A Forti implementa a integração entre o Tasy e a RNDS. O evento assistencial é capturado no ERP, convertido para os recursos FHIR R4 exigidos pelo guia da RNDS e notificado com a assinatura e a autenticação que a plataforma exige.
Mesma cobertura para o MV. O trabalho concentra-se no mapeamento entre o modelo de dados do ERP e os perfis FHIR da RNDS — é nesse ponto que a integração costuma travar, não no transporte.
O TrakCare é da InterSystems, a mesma fabricante do IRIS for Health usado como plataforma de integração. A Forti é parceira InterSystems Partner Select e trabalha nos dois lados dessa pilha.
Outro ERP, sistema próprio ou legado sem documentação? O caminho é o mesmo — veja o fechamento desta página.
Precisa de gente que já conheça esses sistemas dentro da sua equipe? Analistas e desenvolvedores Tasy e Soul MV também podem ser alocados — ver alocação de profissionais.
A notificação é feita por API REST. O que sustenta a conexão:
A RNDS identifica o paciente por CNS ou CPF. Sem um dos dois, o registro não pode ser notificado — não é uma validação que se contorne no meio do caminho, é o identificador do cidadão na rede.
É aqui que os projetos encalham. O identificador não é capturado de forma consistente no atendimento: cadastro antigo sem CPF, paciente inconsciente na emergência, campo preenchido com dado inválido só para liberar a tela. O sistema segue funcionando normalmente — a lacuna só aparece quando a notificação falha.
Isso não se resolve apenas na camada de integração. Resolve-se tornando a lacuna visível: identificar quais atendimentos estão sem identificador válido, separar o que dá para enriquecer retroativamente do que precisa voltar ao fluxo assistencial, e medir a cobertura ao longo do tempo em vez de descobrir o problema pela fila de erro.
Dez anos dedicados ao setor de saúde, ~90 profissionais e domínio dos padrões que conectam sistemas clínicos — HL7 v2.x, FHIR R4, DICOM, TISS, SOAP e REST.
Nenhum protocolo ou regra de negócio é obstáculo. Integrações fora do padrão são viáveis: sistema legado sem API, formato proprietário, regra clínica que só existe naquele hospital. O ponto de partida é sempre o mesmo — entender o dado na origem.