Imagine o seguinte cenário: um paciente entra no canal digital de um hospital e pergunta: ‘Quero marcar uma consulta com um cardiologista para esta semana’.

O agente responde rapidamente, identifica a especialidade, mantém uma conversa natural e até demonstra conhecer a unidade procurada, no que parece ser um bom atendimento.

Até chegar a hora de concluir o agendamento.

Sem acesso à disponibilidade real das agendas, às regras de marcação e aos dados necessários para confirmar aquele atendimento, o agente precisa interromper o fluxo e orientar o paciente a ligar para a central. Vemos que a conversa funcionou, mas o atendimento, não.

Esse é um dos principais pontos que precisam ser avaliados por CIOs, CTOs, gestores de TI e diretorias antes da contratação de um agente de IA na saúde: não basta saber conversar. O agente precisa conseguir acessar os sistemas e executar as ações que promete ao paciente.

Entenda o que fazer para evitar essa situação:

O que é um barramento de interoperabilidade?

Um barramento de interoperabilidade é uma camada tecnológica que conecta diferentes sistemas e permite que dados e informações circulem entre eles de forma padronizada e controlada. Na saúde, ele pode integrar sistemas clínicos, administrativos e canais digitais, reduzindo a necessidade de construir e manter múltiplas conexões isoladas.

Na prática, o barramento funciona como uma camada intermediária entre sistemas que precisam trocar informações. Assim, um agente de IA pode consultar dados de diferentes fontes sem precisar desenvolver uma integração independente para cada novo sistema ou canal.

Qual a diferença entre API, integração ponto a ponto e barramento?

Embora os três conceitos estejam relacionados, eles resolvem problemas diferentes, veja:

Uma API (Application Programming Interface) é uma interface que permite que um sistema disponibilize determinadas funções ou dados para serem acessados por outro sistema. Já a integração ponto a ponto é uma conexão direta entre dois sistemas. O barramento de interoperabilidade, por sua vez, cria uma camada capaz de centralizar e organizar múltiplas integrações.

Para entender a diferença, imagine um hospital com um sistema de gestão, uma plataforma de atendimento digital, um sistema de resultados e um agente de IA.

Se cada solução precisar conversar diretamente com todas as outras, a arquitetura pode se tornar progressivamente mais complexa, pois cada nova conexão cria outra dependência para desenvolver, monitorar, atualizar e manter.

Com um barramento, a lógica muda: os sistemas se conectam a uma camada de integração, que organiza a comunicação entre as diferentes pontas.

Essa arquitetura é especialmente relevante quando a instituição precisa conectar novos canais, fornecedores ou aplicações sem transformar cada nova iniciativa em um projeto isolado de integração.

Ainda assim, isso não significa que um barramento seja sempre a melhor escolha.

Em ambientes menores, com poucas aplicações e uma necessidade muito específica, uma integração ponto a ponto pode ser mais simples e adequada. O ponto não é escolher a arquitetura mais sofisticada, mas aquela que corresponde à complexidade atual e à evolução esperada da instituição.

Quais são os três caminhos para integrar sistemas hospitalares?

Existem três caminhos principais para conectar sistemas hospitalares: integração ponto a ponto, desenvolvimento interno de uma camada de integração e uso de um barramento de interoperabilidade. A escolha não deve partir da tecnologia mais sofisticada, mas da complexidade da operação, da quantidade de sistemas envolvidos e da capacidade que a instituição tem ou pretende ter para sustentar essas conexões.

Integração ponto a ponto

Na integração ponto a ponto, dois sistemas são conectados diretamente para trocar dados ou executar determinadas funções. É uma abordagem relativamente simples quando existe uma necessidade específica e poucas conexões envolvidas.

Por isso, ela continua fazendo sentido em alguns cenários: uma clínica que precisa conectar apenas duas aplicações para resolver um fluxo bem delimitado, por exemplo, pode não precisar de uma camada adicional de integração.

O problema aparece quando a quantidade de sistemas e conexões começa a crescer. A cada nova integração, surge mais uma relação para desenvolver, monitorar, documentar e manter. Com o tempo, alterações em um sistema podem exigir ajustes em diversas conexões, aumentando a complexidade da arquitetura.

Desenvolvimento interno

Outra possibilidade é desenvolver internamente a própria camada de integração. Nesse modelo, a instituição mantém sob seu controle a arquitetura, o desenvolvimento e a evolução das conexões entre seus sistemas.

A alternativa pode ser interessante para organizações que já possuem uma equipe de tecnologia robusta, conhecimento especializado e uma estratégia de longo prazo para assumir essa responsabilidade. Afinal, não se trata apenas de construir as integrações. É preciso monitorá-las, corrigir falhas, acompanhar mudanças nas APIs, garantir segurança, documentar fluxos e manter a arquitetura preparada para novos projetos.

Por isso, o custo desse modelo não está apenas no desenvolvimento inicial. Existe também uma demanda contínua de pessoas, conhecimento e infraestrutura para sustentar a camada de integração ao longo do tempo.

Barramento de interoperabilidade

O terceiro caminho é utilizar um barramento de interoperabilidade, uma camada intermediária que organiza a comunicação entre diferentes sistemas e aplicações.

Em vez de criar uma conexão independente para cada novo projeto, os sistemas podem se conectar ao barramento, que passa a centralizar e estruturar essas trocas. Isso ganha relevância em ambientes com muitos sistemas, canais digitais, parceiros e diferentes fluxos de atendimento.

Além de facilitar a expansão da arquitetura, o barramento pode contribuir para a padronização dos formatos, a governança das integrações, a rastreabilidade das transações e a manutenção das conexões.

Isso não significa, entretanto, que um barramento seja automaticamente a melhor escolha. Se a instituição possui poucas integrações, baixa complexidade e uma necessidade muito específica, uma conexão ponto a ponto pode ser mais simples e eficiente. Da mesma forma, organizações com uma equipe interna especializada podem optar pelo desenvolvimento próprio.

A questão central é entender qual arquitetura consegue sustentar o nível de integração que a instituição precisa hoje e pretende alcançar amanhã.

Para um agente de IA na saúde, essa decisão se torna ainda mais importante. Afinal, quanto mais ações o agente precisar executar (consultar agendas, validar regras, identificar profissionais, verificar convênios ou concluir um agendamento) maior será a dependência de conexões confiáveis com os sistemas que controlam essas informações.

Por que instituições que já têm time de TI ainda contratam uma solução de integração?

Ter uma equipe interna de tecnologia não significa, necessariamente, ter capacidade disponível para assumir todos os componentes de um projeto de IA conversacional.

Um agente de IA voltado ao atendimento do paciente envolve diferentes camadas: experiência conversacional, regras de negócio, acesso a dados, integração com sistemas hospitalares, segurança, monitoramento e evolução contínua.

Além disso, a equipe interna normalmente precisa equilibrar esse projeto com sistemas críticos, infraestrutura, segurança da informação, sustentação, projetos regulatórios e outras prioridades estratégicas.

Nesse contexto, contratar uma solução especializada pode significar complementar a capacidade existente, e não substituí-la.

A decisão, portanto, não deveria ser terceirizar ou fazer internamente, mas se perguntar quais partes da arquitetura a instituição quer e consegue sustentar internamente e quais exigem uma capacidade especializada de integração?

Esse critério também ajuda a evitar um problema comum: contratar um agente de IA antes de definir como ele terá acesso confiável às informações necessárias para executar suas tarefas.

Como a interoperabilidade permite que o agente faça mais do que responder?

A diferença aparece quando o agente deixa de ser apenas uma interface de conversa e passa a participar de fluxos operacionais.

Em vez de responder ‘temos cardiologistas na unidade X’ ele pode consultar os sistemas conectados, verificar profissionais e horários disponíveis, aplicar as regras de agendamento, considerar a unidade e o convênio e conduzir o paciente até a conclusão da solicitação.

Essa capacidade depende da integração entre as diferentes camadas da operação.

Além disso, a interoperabilidade na saúde não diz respeito apenas à troca de dados. Ela também envolve padronização, rastreabilidade, governança e segurança.

Padrões como HL7 e FHIR ajudam a estruturar a comunicação de informações em diferentes contextos. APIs permitem expor funcionalidades e dados de maneira controlada. E uma arquitetura de integração bem definida ajuda a organizar como essas informações circulam entre os sistemas.

Para dados de saúde, existe ainda uma camada fundamental: a LGPD.

Informações relacionadas à saúde são consideradas dados pessoais sensíveis pela legislação brasileira. Por isso, qualquer arquitetura que permita a um agente acessar ou manipular essas informações precisa considerar controles de acesso, segurança, finalidade de uso, rastreabilidade e governança dos dados.

Em outras palavras, fazer o agente acessar mais dados não é suficiente. É necessário garantir que ele acesse os dados certos, pelo meio certo e dentro das regras certas.

O que o Nuria MyConnect tem a ver com esse cenário?

Na Nuria, nós trabalhamos com interoperabilidade como uma camada para conectar diferentes sistemas e viabilizar fluxos digitais na saúde.

O Nuria MyConnect é o nosso barramento de interoperabilidade e conta com mais de 290 APIs voltadas exclusivamente para a saúde, além da capacidade de desenvolver novos conectores sob demanda.

Essa estrutura permite conectar healthtechs e soluções digitais aos sistemas utilizados por hospitais e clínicas. Entre as empresas já conectadas estão MEMED e Anestech, em integrações com instituições de saúde.

O objetivo não é fazer com que cada novo agente de IA precise começar a arquitetura de integração do zero. É criar uma camada capaz de organizar as conexões necessárias para que diferentes tecnologias consigam acessar e movimentar informações de forma estruturada.

É essa camada que pode transformar um agente que apenas responde em uma tecnologia capaz de participar de um fluxo real de atendimento.

Quais perguntas fazer antes de contratar um agente de IA para o atendimento ao paciente?

Antes de avaliar apenas a qualidade da conversa, a instituição deve entender o que o agente consegue acessar, quais ações consegue executar e como essas ações são integradas à operação.

Use este checklist em uma avaliação técnica ou comercial:

O agente consegue consultar a disponibilidade real das agendas?
Não basta ter horários previamente carregados. A solução precisa conseguir trabalhar com a disponibilidade efetivamente disponível para agendamento.

Quais sistemas hospitalares o agente consegue acessar?
Pergunte quais integrações já existem, quais sistemas podem ser conectados e como novos conectores são desenvolvidos.

O agente consegue executar ações ou apenas consultar informações?
Diferencie claramente uma resposta informativa de uma ação transacional, como agendar, cancelar ou alterar um atendimento.

Como as regras de negócio do hospital são aplicadas?
A solução precisa respeitar regras relacionadas a agendas, profissionais, unidades, convênios, tipos de atendimento e demais restrições operacionais.

Como a integração é mantida quando um sistema muda?
Entenda quem monitora as conexões, como alterações são identificadas e como a manutenção da integração é realizada.

Como os dados sensíveis são protegidos e rastreados?
Avalie controles de acesso, segurança, rastreabilidade e aderência aos requisitos aplicáveis à LGPD e aos dados de saúde.

A arquitetura suporta novos canais, sistemas e casos de uso?
Um projeto que funciona para um único fluxo pode se tornar um problema se cada nova expansão exigir uma integração isolada.

Qual é a estratégia de interoperabilidade por trás do agente?
Mais importante do que perguntar apenas qual modelo de IA está sendo utilizado é entender como a tecnologia se conecta à operação que precisa executar.

Essas perguntas mudam a avaliação do projeto. Em vez de comparar agentes apenas pela qualidade da conversa, a instituição passa a analisar a capacidade de transformar uma conversa em uma ação operacional.

Se, no fim da conversa, o paciente ainda precisa recorrer à central para concluir o que começou no canal digital, existe uma lacuna entre o agente de IA e a operação do hospital. 

Quer entender como preencher essa lacuna? Fale com a Nuria e conheça o Nuria MyConnect. 

FAQ: agente de IA e integração na saúde

O que é um agente de IA na saúde?

Um agente de IA na saúde é uma tecnologia capaz de interagir com pacientes e, quando está conectado aos sistemas necessários, executar ações relacionadas ao atendimento. Diferentemente de um chatbot exclusivamente informativo, ele pode consultar dados, aplicar regras e conduzir fluxos como agendamentos, cancelamentos e alterações de atendimento.

O que é interoperabilidade na saúde?

Interoperabilidade na saúde é a capacidade de diferentes sistemas e aplicações trocarem informações de maneira estruturada, segura e compreensível. Ela permite conectar dados e processos entre tecnologias utilizadas por hospitais, clínicas, healthtechs e canais digitais, criando uma operação mais integrada.

O que é um barramento de interoperabilidade?

Um barramento de interoperabilidade é uma camada tecnológica que centraliza e organiza a comunicação entre diferentes sistemas. Em vez de criar conexões independentes entre cada aplicação, o barramento permite estruturar múltiplas integrações, facilitando a expansão, o monitoramento e a manutenção da arquitetura.

API é a mesma coisa que barramento de interoperabilidade?

Não. Uma API é uma interface que permite que um sistema disponibilize dados ou funcionalidades para serem acessados por outra aplicação. Já o barramento de interoperabilidade é uma camada que organiza diferentes conexões e pode utilizar APIs para viabilizar a comunicação entre sistemas, aplicações e canais.

Por que a agenda real é importante para um agente de IA?

Porque um agente que não consegue consultar a disponibilidade real pode informar horários sem conseguir garantir que eles estejam disponíveis para agendamento. Para concluir o fluxo, o agente precisa acessar a fonte que controla a agenda, considerar as regras de agendamento e executar a ação necessária no sistema.