A recomendação de manual é clara: sistemas devem conversar por APIs e middlewares de integração, com contrato definido, versionamento e uma camada que isole cada lado das mudanças do outro.
Na prática, integrações diretas via banco de dados continuam sendo a realidade de boa parte das instituições de saúde. E o motivo é compreensível: não exigem nova infraestrutura, não pedem servidor de integração ou containers, não obrigam a equipe a manter código em outra linguagem. Um pacote PL/SQL resolve em dias o que um projeto de middleware levaria meses para entregar.
Este artigo não é sobre abandonar essa prática. É sobre executá-la com disciplina — porque a diferença entre uma integração via banco bem feita e uma mal feita não aparece no dia da entrega. Aparece na próxima atualização de versão do ERP, quando o fornecedor pergunta o que foi alterado no ambiente.
Separe o que é seu do que é do fornecedor
O erro mais comum é também o mais silencioso: criar objetos de customização dentro do próprio schema do ERP, misturados aos objetos originais.
O ideal é criar um schema próprio para as customizações e conceder a ele apenas os acessos que a integração realmente precisa, via GRANT específico. Isso estabelece uma fronteira física entre o que é do fornecedor e o que é da instituição, e a fronteira se paga sozinha na primeira auditoria ou no primeiro upgrade.
Quando isso não for possível e tudo precisar conviver no mesmo schema, adote no mínimo um padrão de nomenclatura rígido para os objetos próprios — um prefixo consistente, aplicado sem exceção. Alguns ERPs, como o Bionexo Tasy, gerenciam bem o próprio catálogo e conseguem distinguir o que é do cliente. Ainda assim, esse controle precisa existir do lado da TI: em um cenário com várias integrações e customizações convivendo, alguém vai precisar responder rapidamente qual objeto pertence a qual integração, e o que quebra se ele for alterado.
Não altere objetos do ERP
Esta é a regra que não comporta exceção. Procedures, functions, triggers, views e tabelas que vieram com o sistema devem permanecer intactos.
São três os motivos, e cada um sozinho já bastaria:
- A alteração se perde, e você não é avisado. Este é o ponto central. O fornecedor pode atualizar aquele objeto a qualquer momento, e quando isso acontece a sua modificação simplesmente desaparece — sobrescrita pela versão original. Junto com ela vai embora toda a funcionalidade que dependia daquele ajuste. Não há aviso, não há erro de compilação, não há registro no upgrade dizendo o que foi substituído. A integração para de funcionar em silêncio, e alguém vai descobrir dias depois, pelo efeito.
- Risco funcional. Alterar uma rotina do ERP significa mudar a lógica de um sistema que você não escreveu e cuja abrangência total ninguém na instituição conhece. O efeito colateral raramente aparece no módulo que foi mexido.
- Risco contratual. Muitos contratos de licenciamento proíbem expressamente a modificação dos objetos do sistema, justamente pelo risco envolvido. Ao alterar, a TI assume um risco que era do fornecedor — e pode perder suporte exatamente no momento em que mais precisa dele.
Vale insistir num ponto: a boa intenção não muda nada disso. Corrigir um comportamento que a instituição considera errado, otimizar uma consulta lenta ou acrescentar uma validação que faz todo sentido para a operação — todos esses ajustes, por mais defensáveis que sejam, têm o mesmo destino na próxima atualização. O critério não é o mérito da mudança; é a propriedade do objeto.
Quando a necessidade realmente exige alterar um objeto do sistema, o caminho é a fabricante. Abra o chamado, descreva o comportamento esperado e deixe que a mudança venha pela linha oficial do produto. É mais lento, e essa demora costuma ser o argumento para fazer por conta própria — mas é a única forma de a alteração sobreviver aos upgrades e continuar sendo responsabilidade de quem escreveu o sistema.
Do lado da instituição, a alternativa é sempre criar objetos próprios, que convivem com o ERP sem alterá-lo.
A zona cinzenta que merece atenção
Existe um caso intermediário que vale nomear, porque é onde a maioria das integrações reais vive: criar um objeto próprio que reage a eventos do ERP — uma trigger sobre uma tabela do sistema, por exemplo.
Tecnicamente, o objeto é seu e o do fornecedor continua intacto. Mas ele passa a participar da transação do ERP, e isso exige cuidados que não se aplicam a um pacote isolado. Mantenha a lógica fora da trigger, em package próprio, para que a leitura do fluxo continue possível. Trate exceções de forma que uma falha na sua rotina nunca derrube uma operação assistencial. E verifique o que o contrato de licenciamento diz a respeito — a resposta varia por fornecedor e por versão do contrato.
Prefira as rotinas do próprio sistema
Cuidado redobrado com qualquer rotina que grave dados na base — inserções, exclusões e, muito especialmente, operações de atualização.
Uma operação de atualização executada fora do fluxo do sistema grava o dado, mas não faz nada do que o ERP faria em volta dele. Não passa pelas validações que impediriam o valor inválido. Não respeita os parâmetros configurados naquela instituição, que muitas vezes mudam o comportamento esperado. Não propaga a mudança para os registros dependentes em outros módulos, nem alimenta os controles que o sistema mantém em paralelo — histórico, situação, saldos, rastreabilidade.
O registro alterado passa a contar uma história diferente da que o restante da base conta.
E como o dado está lá, gravado e visível na tela, nada indica que algo saiu do lugar: a divergência costuma aparecer semanas depois, em um módulo distante, sob a forma de um número que não fecha ou de um comportamento que ninguém consegue explicar.
Sempre que existir uma rotina do próprio sistema que execute a operação desejada, use essa rotina em vez de escrever o comando. Ela já considera os parâmetros e as configurações do ambiente. Antes de usá-la, estude com critério: entenda a lógica, mapeie os objetos envolvidos e as dependências. Ferramentas de IA ajudam bastante nessa etapa de mapeamento e de validação do entendimento, mas não substituem o teste em homologação — elas confirmam hipóteses, não garantem comportamento.
Crie um plano de validação para as atualizações
Toda atualização do sistema principal deveria ter um roteiro de validação. Com customizações e integrações no ambiente, isso deixa de ser boa prática e vira necessidade.
Monte um checklist com as ações a executar e o resultado esperado de cada uma, cobrindo especificamente os pontos que suas integrações tocam. Executado a cada upgrade, ele transforma a atualização de um evento de risco em um procedimento previsível — e encurta drasticamente o tempo entre “algo quebrou” e “sabemos o quê”.
Estabeleça uma política de aprovação para alterações em dados
Em muitas instituições, analistas têm acesso direto ao banco para fazer ajustes pontuais, mesmo sem qualquer projeto de integração em curso. Se esse é o seu caso, vale criar uma política formal de aprovação.
Toda rotina que altere dados passa por uma equipe com visão dos sistemas envolvidos, que avalia a segurança do ajuste e registra a alteração. O custo é baixo e o retorno é direto: se a operação convive com comportamentos que ninguém consegue explicar, alterações não documentadas feitas direto na base costumam estar entre as causas — e sem registro, a investigação não tem por onde começar.
Revise também as consultas
Comandos de leitura parecem inofensivos e por isso escapam de qualquer revisão. Não deveriam.
É comum encontrar consultas com problemas sérios de performance, e mais comum ainda encontrar DISTINCT usado como remendo: a junção está errada, produz linhas repetidas, e em vez de corrigir o relacionamento o analista elimina as duplicatas. O resultado passa a parecer correto sem estar — e a consulta ainda paga o custo de processar e ordenar tudo o que vai descartar.
Duas medidas simples cobrem a maior parte disso. A primeira é definir um conjunto mínimo de verificações que o próprio analista aplica antes de subir qualquer consulta ao ambiente. A segunda é monitorar: peça ao DBA um relatório periódico das instruções de maior custo no ambiente. Muitas vezes o ajuste é um índice, e o ganho aparece em rotinas que ninguém sabia que estavam pesando.
Integração é projeto, não tarefa
A diversidade de sistemas e a busca por produtividade tornaram integrações e customizações uma necessidade permanente na saúde. O que muda entre uma instituição e outra não é se elas existem — é se foram tratadas como projeto, com fronteira definida, documentação e plano de validação, ou como tarefa resolvida no improviso e esquecida até o dia em que falha.
Somos especialistas nos sistemas mais utilizados na área da saúde e ajudamos a construir integrações seguindo essas práticas, com a documentação necessária para que a instituição mantenha o controle do próprio ambiente.