Motores de interface explicados

Resposta curta: um motor de interface (motor de integração) é um middleware criado para a comunicação em saúde. Ele escuta em muitos protocolos (MLLP para HL7 v2, HTTP para FHIR e SOAP, ficheiros, bases de dados, filas), transforma mensagens (mapeamento de campos, tradução de códigos, conversão de formatos como HL7 v2 para FHIR), roteia-as para um ou vários destinos com filtros, e mantém filas, tentativas, registos e painéis de controlo para que uma mensagem nunca se perca e cada falha seja visível. Hospitais usam um para que cada sistema seja ligado ao motor uma vez, em vez de a todos os outros sistemas. Os produtos conhecidos são Mirth Connect (NextGen Connect, historicamente código aberto), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion e uma longa lista; os fornecedores de cloud oferecem equivalentes geridos.

Os blocos de construção

Os blocos de construção de um motor de interface são canais (um fluxo de uma origem para os seus destinos), conectores ou ouvintes de origem como MLLP e HTTP, filtros que decidem se uma mensagem continua, transformadores que mapeiam campos e códigos, conectores de destino, filas com retentativas, monitorização com alertas e um registo de auditoria das alterações de canal e do histórico de mensagens.

Todo o motor, independentemente do vocabulário, tem as mesmas partes:

Canal (interface): um fluxo de uma origem para um ou mais destinos, com as suas próprias definições e estatísticas.
Conector/escuta de origem: MLLP (TCP com enquadramento para HL7 v2), pontos de extremidade HTTP(S), SFTP e sondagem de ficheiros, consultas a bases de dados, filas JMS ou outras, DICOM em alguns produtos.
Filtro: uma regra que decide se uma mensagem continua (apenas ADT^A01 para esta classe de paciente).
Transformador: scripts ou mapeamentos que alteram a mensagem: renomear campos, mapear códigos locais para LOINC através de uma tabela de consulta, construir uma Observação FHIR a partir de um segmento OBX, adicionar um segmento Z que um sistema legado espera.
Conector de destino: para onde vai o resultado, com o seu próprio protocolo e tratamento de erros.
Fila e tentativa: as mensagens persistem até serem reconhecidas; as falhas tentam novamente com back-off; mensagens "poison" (problemáticas) vão para uma fila de erros para humanos.
Monitorização e alerta: contadores por canal, latência, taxas de erro, alertas quando um canal fica silencioso (o alerta mais útil em integração de saúde).
Auditoria: quem alterou qual canal, e o histórico da mensagem para resolução de problemas, com retenção e controlos de acesso porque são dados do paciente.

Tarefas típicas

As tarefas típicas de um motor de interface de cuidados de saúde são a distribuição ADT do HIS para os departamentos, o encaminhamento de resultados laboratoriais para vários recetores, a tradução de códigos locais para LOINC, ATC e UCUM, a ligação entre formatos HL7 v2, FHIR, CDA e CSV, a exposição de uma fachada FHIR sobre uma base de dados legada, a normalização de fluxos de dispositivos e a adaptação de MLLP interno para HTTPS externo.

Fan-out ADT: receber admissões do HIS, filtrar e traduzir por departamento, entregar ao laboratório, radiologia, farmácia, gestão de camas e portal do paciente.
Roteamento de resultados: ORU do LIS para o EHR, para o sistema do médico prescritor, para o registo regional, para o registo FHIR do paciente, cada um com um subconjunto e formato diferentes.
Tradução de códigos: códigos de teste locais para LOINC, códigos de medicamentos locais para ATC, unidades de texto livre para UCUM, através de tabelas de consulta mantidas (mapear códigos de laboratório para LOINC).
Ponte de formatos: HL7 v2 para FHIR e vice-versa, CDA para FHIR, CSV de um sistema antigo para qualquer formato.
Uma fachada FHIR: o motor expõe pontos de extremidade FHIR e responde a eles consultando a base de dados legada ou enviando consultas v2, para que as aplicações vejam um servidor FHIR onde nenhum existe.
Integração de dispositivos: feeds proprietários de monitores normalizados para observações IHE PCD.
Adaptação de protocolo: MLLP dentro do edifício, HTTPS com OAuth para o exterior.

Escolher um

A escolha de um motor de interface resume-se a seis critérios: volume de mensagens e quão críticos são a latência e as interrupções, os protocolos e normas suportados de imediato (HL7 v2, FHIR R4, DICOM, formatos nacionais), experiência do programador, operações como clustering e failover, termos de licenciamento, que mudaram para alguns produtos em 2025, e as competências disponíveis para manter os canais.

Volume e criticidade: mensagens por dia, latência aceitável e se uma interrupção de dois minutos importa (importa para ADT e resultados).
Protocolos e normas prontos a usar: versões e analisadores HL7 v2, suporte FHIR R4 com validação, DICOM, X12 nos EUA, formatos nacionais.
Experiência do programador: linguagem de scripting (JavaScript no Mirth, proprietária noutros), controlo de versão de definições de canal, ferramentas de teste, implementação em vários ambientes.
Operações: clustering, failover, integrações de monitorização, caminho de atualização, modelo de suporte.
Licenciamento: código aberto ou edições comunitárias, subscrição por canal ou por núcleo, ofertas geridas na cloud; o licenciamento de alguns produtos historicamente abertos mudou em 2025, por isso verifique os termos atuais.
Competências disponíveis: o motor é tão bom quanto as pessoas que mantêm os canais.

Executar um em segurança

Executar um motor de interface em segurança significa tratar as definições de canal como código sob controlo de versão, testar com mensagens sintéticas antes da produção, gerir tabelas de consulta de código com proprietários nomeados, alertar quando um canal fica silencioso, restringir e purgar o histórico de mensagens porque são dados do paciente, documentar o propósito de cada canal e nunca deixar que o motor se torne o sistema de registo.

Trate as definições de canal como código: em controlo de versão, revisto, implementado através de testes e staging com mensagens sintéticas. Mantenha as tabelas de consulta (mapas de códigos) sob governação com proprietários. Defina alertas para silêncio, não apenas para erros. Restrinja o acesso ao histórico de mensagens, que são dados do paciente, e elimine-o num cronograma. Documente o propósito e o proprietário de cada canal; o canal não documentado é aquele que para um departamento quando o seu autor sai. E nunca deixe o motor tornar-se o sistema de registo: ele move e transforma dados, não os possui.

Quando não precisa de um

Um motor de interface não é necessário quando todos os parceiros de um sistema novo falam FHIR, caso em que um servidor FHIR com Subscriptions e um gateway de API cobrem o encaminhamento e a autenticação, ou quando uma única interface HL7 v2 pode ser tratada por uma biblioteca como HAPI HL7v2 ou hl7apy. O motor justifica o seu lugar com muitos sistemas e formatos.

Um sistema "greenfield" cujos parceiros falam todos FHIR pode usar um servidor FHIR com Subscrições e um API gateway para autenticação, limitação de taxa e roteamento, com transformações em serviços comuns. Uma única interface HL7 v2 pode ser tratada por uma pequena biblioteca (HAPI HL7v2 em Java, hl7apy ou python-hl7 em Python) dentro da aplicação. O motor ganha o seu lugar quando existem muitos sistemas, muitos formatos e a necessidade de uma consola de operações que não programadores possam observar.

Em Anpheros

A Plataforma Anpheros está no lado FHIR do motor: os hospitais roteiam os fluxos que querem partilhar (resultados, documentos, encontros) para ela através do seu motor ou através do conector de laboratório, e leem de volta através de APIs FHIR e webhooks. O site para programadores mostra o mapeamento HL7 v2 para FHIR que o conector aplica.

Páginas relacionadas

Fontes

Perguntas frequentes

Um motor de interface é o mesmo que um ESB ou um iPaaS?

Mesma família, especializado: um motor de interface vem com suporte HL7 v2, DICOM, CDA e FHIR, MLLP, monitorização específica para saúde e a integração de vocabulário que as equipas usam. ESBs gerais e produtos iPaaS podem fazer o trabalho com mais construção.

O motor pode converter HL7 v2 para FHIR automaticamente?

Vários motores incluem mapeamentos baseados no guia HL7 v2 para FHIR, e eles lidam com os segmentos comuns. Convenções locais, segmentos Z e mapeamento de códigos sempre precisam de trabalho de projeto.

O motor armazena dados do paciente?

Ele persiste mensagens em trânsito e mantém o histórico de mensagens para resolução de problemas, que são dados do paciente e devem ser protegidos e eliminados. Não deve ser usado como um armazenamento a longo prazo ou um sistema de registo.

Código aberto ou comercial?

Ambos estão em produção em grandes hospitais. A decisão geralmente recai sobre o suporte, competências, necessidades de clustering e os termos de licenciamento atuais, que mudaram para alguns produtos; verifique antes de se comprometer.

Anpheros Platform

Experimente grátis no sandbox

Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.

Criar um sandbox grátis Ler os guias para programadores →

Grátis · 30 pacientes sintéticos · sem cartão

Este guia é meramente informativo e não substitui aconselhamento médico. Para decisões sobre a sua saúde, fale com o seu médico. Em uma emergência, ligue para o número de emergência local (112 na Europa).

Escrito por

A equipa Anpheros

A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.

Sobre a Anpheros →