Hub analítico · interfaceamento
Interfaceamento e host query
Interfaceamento é a conversa entre o sistema de informação e o analisador. Ela tem duas direções, três modos de operação e um punhado de protocolos de trinta anos de idade que continuam em produção. Entender essa conversa é a diferença entre digitar tudo à mão e ter o resultado aparecendo na tela antes de alguém pedir.
01As duas direções
Toda integração com analisador é feita de duas conversas independentes. Elas podem existir separadamente, e muita instalação tem só uma.
Download — sistema → equipamento
A lista de trabalho: quais amostras, com quais testes. É o que evita que o operador digite a programação no teclado do analisador.
Upload — equipamento → sistema
Os resultados brutos, com flags, unidade, data-hora da medição e, quando disponível, o identificador do equipamento e do reagente.
Guarde: a direção de upload é a que traz o ganho maior e é a mais simples de implantar. Se houver que escolher uma para começar, é ela: elimina o erro de transcrição, que é o mais silencioso de todos porque produz um número plausível.
02Os três modos de operação
| Modo | Como funciona | O que exige | O que sobra de trabalho manual |
|---|---|---|---|
| Unidirecional | o equipamento envia resultado; nada volta | só o receptor no lado do sistema | programar o analisador à mão, teste por teste |
| Bidirecional por lote | o sistema empurra a lista antes da corrida | lista pronta antes de começar | reenviar o lote quando entra amostra nova |
| Bidirecional por consulta (host query) | o equipamento lê o código de barras e pergunta o que fazer | código de barras na amostra e resposta rápida | praticamente nada |
Por que host query é o alvo: nos outros dois modos, alguém tem de antecipar o que vai rodar. Na consulta, a amostra chega e o equipamento pergunta — então uma amostra que entrou depois do lote ser montado é tratada igual às outras. É o modo que absorve o imprevisto, e imprevisto é a regra na rotina.
03Host query, passo a passo
O nome descreve exatamente o que acontece: o equipamento consulta o host. Vale conhecer a sequência porque quase toda falha de integração acontece num destes seis passos.
- 1O equipamento lê o código de barras: O tubo passa pelo leitor. O equipamento agora tem um identificador e nada mais — não sabe de quem é nem o que fazer.
- 2Pergunta ao sistema: Envia uma consulta: “o que devo fazer com este identificador?”. Neste momento ele está parado, esperando.
- 3O sistema resolve o identificador: Localiza a amostra, confere se ela existe, se está no estado certo e se aquele equipamento é destino válido para os testes pendentes.
- 4Responde com a lista de testes: Só os testes que aquele equipamento deve fazer, agora. Não os já feitos, não os de outro setor, não os já enviados a outra plataforma.
- 5O equipamento executa e devolve: Roda os testes e envia o resultado de cada um, com flags, unidade e hora da medição.
- 6O sistema reconhece o recebimento: Confirma o que recebeu. Sem isso, o equipamento pode reenviar — ou pode considerar entregue algo que nunca chegou.
A resposta tem de ser específica: a consulta é por amostra, mas a resposta é por amostra + equipamento + estado. Responder a lista inteira do pedido é o erro clássico: o analisador reexecuta o que já foi feito, o consumo de reagente sobe, e o resultado que chega de volta sobrescreve — ou conflita com — o que já estava lá.
04Os protocolos
Nada aqui é novo, e isso é uma vantagem: são padrões estáveis, com implementações maduras em praticamente todo equipamento de laboratório clínico.
| Padrão | Para que serve | Onde aparece |
|---|---|---|
| ASTM E1381 / E1394 | transporte serial e mensagem de resultado clínico | a maioria dos analisadores instalados — inclusive sobre TCP/IP |
| HL7 v2 (ORM, ORU, ACK) | pedido, resultado e reconhecimento entre sistemas | equipamentos mais novos e integrações entre sistemas |
| POCT1-A | dispositivos de teste laboratorial remoto (point-of-care) | glicosímetros, gasometria à beira do leito |
| LIS2-A2 (CLSI) | a especificação que consolida a prática de ASTM em laboratório clínico | referência de implementação |
| Proprietário do fabricante | quando o equipamento não fala nenhum dos acima como deveria | mais comum do que se gostaria |
O que a variedade significa para o produto: não é possível escrever “o” parser. O que se escreve é um adaptador por modelo de equipamento convertendo para um contrato interno único. O contrato interno é o ativo; os adaptadores são descartáveis e se acumulam com o tempo. Inverter isso — deixar o formato do fabricante vazar para dentro do sistema — é a decisão de arquitetura que mais dói depois.
05O de-para
O equipamento chama o teste de GLU. O sistema chama de GLI. Uma tabela resolve. O que essa tabela precisa guardar, porém, é mais do que dois códigos.
| O que mapear | Por quê | O que dá errado sem isso |
|---|---|---|
| Código do teste | os dicionários são diferentes | o resultado chega e não encontra onde entrar |
| Unidade | o equipamento pode medir em outra unidade | número certo, grandeza errada — o erro mais perigoso |
| Fator de conversão | quando a unidade difere por escala | valor 10× ou 1000× fora, e às vezes plausível |
| Casas decimais | a precisão de exibição é decisão do laboratório | laudo com precisão falsa ou perdida |
| Códigos de flag | cada fabricante tem o seu vocabulário | alerta do equipamento ignorado silenciosamente |
| Faixa mensurável | abaixo ou acima dela, o número não é um número | reportar “0,0” quando o correto é “< limite” |
A unidade é o campo perigoso: um código de teste não mapeado falha ruidosamente — o resultado não entra e alguém percebe. Uma unidade não mapeada falha silenciosamente: entra um número plausível na grandeza errada, passa pelas faixas de referência do jeito errado, e sai no laudo. Toda integração nova deve ser conferida unidade por unidade antes de sair do modo de observação.
06Middleware: o que é e quando se justifica
Middleware é uma camada entre os analisadores e o sistema de informação. Ela existe porque, historicamente, os sistemas de informação não faziam o que a bancada precisava — e os fabricantes de equipamento passaram a vender a camada junto com a máquina.
| O que o middleware costuma fazer | Precisa ser fora do sistema? |
|---|---|
| Falar o protocolo de cada equipamento | não — é um adaptador, cabe no sistema |
| Autoverificação por regras | não — e é melhor dentro, onde estão o histórico e o cadastro |
| Regras de repetição e diluição | não |
| Controle de qualidade em tempo real | não |
| Pilotar a esteira e o braço robótico | sim — é comando de hardware em tempo real |
| Decidir posição física na esteira | sim |
A leitura honesta: das seis capacidades acima, quatro não têm razão técnica para viver fora do sistema de informação — e ficam melhor dentro, onde estão o histórico do paciente, o cadastro do exame e a trilha de auditoria. As duas que realmente exigem camada dedicada envolvem pilotar hardware em tempo real. Um sistema que implementa as quatro primeiras reduz o middleware ao seu escopo legítimo — e a decisão de comprá-lo volta a ser sobre automação física, não sobre regras.
07Quando a integração cai
Ela cai. A pergunta de projeto não é se, mas o que acontece nos vinte minutos seguintes.
| Falha | Como se manifesta | O que o sistema deve fazer |
|---|---|---|
| Conexão perdida | nada chega, e o silêncio parece normal | heartbeat com alerta por tempo sem contato, e fila de reenvio |
| Mensagem malformada | o parser quebra num item | isolar a mensagem, guardar o texto cru, seguir com as demais |
| Resultado sem amostra correspondente | o identificador não existe no sistema | quarentena visível, nunca descarte — é resultado de paciente |
| Resultado duplicado | o equipamento reenviou | chave de deduplicação estável por amostra + teste + hora |
| Resultado que chega depois da liberação | o laudo já saiu | não sobrescrever: gerar versão e exigir decisão humana |
Nunca descartar mensagem que não casou: um resultado cujo identificador não existe no sistema é, quase sempre, resultado real de paciente real com etiqueta errada ou amostra criada fora do fluxo. Descartar é perder dado clínico. O destino certo é uma fila de quarentena que alguém vê e resolve — e que aparece como número na tela enquanto não estiver vazia.
Resumo do guia: duas direções, três modos, e host query como alvo porque absorve imprevisto; o de-para é maior do que dois códigos e a unidade é seu campo perigoso; quatro das seis funções de middleware cabem melhor dentro do sistema; e a integração vai cair — o que decide é o heartbeat e a quarentena. Com o resultado dentro, começa o trabalho de interpretá-lo.
Ver o ciclo de vida do resultado →Continue no hub de processamento analítico