Resposta curta: uma interface de laboratório tem duas direções. Pedidos vão do EHR para o sistema de informação laboratorial (LIS) como mensagens HL7 v2 ORM^O01 ou OML^O21 (ou como FHIR ServiceRequest), e o LIS responde com ORR/ORL e mais tarde com resultados como ORU^R01 (ou FHIR DiagnosticReport com Observations). As partes difíceis não são as mensagens, mas os detalhes dentro delas: números de colocador e preenchedor que ligam os resultados aos pedidos, estado do resultado (preliminar, final, corrigido), indicadores de anormalidade, unidades e intervalos de referência, informação do espécime, microbiologia com os seus resultados multipartes, e mapeamento de códigos para LOINC. Bem feito, cada resultado chega ao paciente certo, ao pedido certo e ao lugar certo no prontuário, com o seu significado intacto.
Passo 1: acordar os fluxos
O primeiro passo na integração de um sistema de informação laboratorial com um EHR é acordar com o laboratório quais os fluxos existentes: pedidos enviados, atualizações de estado de pedidos, resultados recebidos, correções, cancelamentos, testes adicionais e reflexos, e um feed de dados demográficos ADT para o LIS. As partes também definem a versão do HL7, geralmente 2.3.1 ou 2.5.1, e o transporte, tipicamente MLLP com acusações de receção.
Decida com o laboratório quais fluxos existem: pedidos de saída (ou o laboratório recebe papel e regista-se?), atualizações do estado do pedido, resultados de entrada, correções, cancelamentos, testes adicionais, testes reflexos e dados demográficos (feed ADT para o LIS para que saiba o paciente antes da chegada do espécime). Desenhe a sequência para um resultado normal, um resultado corrigido e um pedido cancelado. Decida a versão HL7 (2.3.1 e 2.5.1 são as mais comuns) e o transporte (MLLP com ACKs; por vezes ficheiros). Ver mensagens de pedido HL7 v2.
Passo 2: a mensagem de resultado, campo a campo
Um resultado laboratorial chega ao EHR como uma mensagem HL7 v2 ORU^R01: MSH identifica o remetente e o destinatário, PID o paciente, PV1 a visita, ORC e OBR contêm os números de pedido do colocador e do executor, o painel encomendado e o estado do relatório, e cada OBX contém um analito com o seu código LOINC, valor, unidades, intervalo de referência, indicador de anormalidade e estado do resultado.
MSH|^~\&|LIS|CENTRALLAB|EHR|GENHOSP|20260314130500||ORU^R01^ORU_R01|RES0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F
PV1|1|O|CLINIC-3^^^GENHOSP
ORC|RE|PLC-778812^EHR|FIL-556701^LIS|||||||||42^SMITH^JOHN
OBR|1|PLC-778812^EHR|FIL-556701^LIS|58410-2^CBC panel - Blood by Automated count^LN|||20260314084000|||||||||42^SMITH^JOHN||||||20260314130000|||F
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||10.9|g/dL|12.0-15.5|L|||F|||20260314125800
OBX|2|NM|6690-2^Leukocytes [#/volume] in Blood by Automated count^LN||6.4|10*3/uL|4.0-10.0|N|||F|||20260314125800
OBX|3|NM|777-3^Platelets [#/volume] in Blood by Automated count^LN||230|10*3/uL|150-400|N|||F|||20260314125800
NTE|1||Mild normocytic anaemia; suggest iron studies if clinically indicated.
- ORC-2 / OBR-2 número do colocador e ORC-3 / OBR-3 número do preenchedor: a ligação ao pedido. OBR-4: o painel, codificado (LOINC
LN). OBR-7: hora da colheita do espécime. OBR-22: hora do relatório de resultados. OBR-25: estado do resultado para todo o pedido (Ppreliminar,Ffinal,Ccorrigido,Xcancelado). - OBX-2: tipo de valor (
NMnumérico,STstring,TXtexto,CE/CWEcodificado,SNnumérico estruturado como<^5). OBX-3: o analito, codificado. OBX-5: o valor. OBX-6: unidades, idealmente UCUM (10*3/uL, nãoK/µL). OBX-7: intervalo de referência como texto. OBX-8: indicadores de anormalidade (L,H,LL,HH,A,N). OBX-11: estado do resultado por analito (P,F,C,X,Deliminado). OBX-14: hora da observação. OBX-19: hora da análise. - NTE: comentários, anexados ao OBR ou a um OBX específico por posição.
- SPM (2.5+): tipo de espécime (SNOMED CT), hora da colheita, hora de receção, condição.
Passo 3: os casos especiais
Os casos especiais que uma interface laboratorial deve tratar são resultados corrigidos (estado C com os números de pedido originais, substituindo e alertando em vez de apagar), resultados preliminares e depois finais, microbiologia com organismos e suscetibilidades ligados por sub-ID, resultados de texto e PDFs incorporados, testes reflexos e adicionais, cancelamentos, e unidades e intervalos de referência que mudam quando o laboratório muda de analisadores.
- Correções: um novo ORU com
Cem OBR-25 e OBX-11 e os mesmos números de colocador/preenchedor; o EHR tem de substituir, sinalizar a alteração e alertar o clínico. Nunca apague o original silenciosamente. - Preliminar e depois final: resultados
P(uma coloração de Gram) seguidos deF(a cultura); o prontuário tem de mostrar o estado. - Microbiologia: um OBX para o organismo identificado (codificado, SNOMED CT), seguido de resultados de suscetibilidade como OBX por antibiótico com o organismo como sub-ID (OBX-4), muitas vezes em várias mensagens. É aqui que se escondem a maioria dos bugs da interface.
- Resultados de texto e PDFs: comentários de patologia e de algumas análises químicas chegam como linhas TX ou como um PDF incorporado (OBX-2
ED); o prontuário precisa tanto do texto como do ficheiro. - Testes reflexos e adicionais: novos OBRs sob o pedido original, ou um novo pedido criado pelo laboratório; acordar como são numerados.
- Cancelamentos: estado
X, com os números originais. - Unidades e intervalos por analisador: o mesmo teste pode mudar de unidades quando o laboratório muda de analisadores; a interface tem de transportar o intervalo com cada resultado, não assumir.
Passo 4: códigos
O mapeamento de códigos numa interface laboratorial significa traduzir os códigos de teste locais do laboratório para LOINC uma vez, numa tabela mantida, e enviar ambos os códigos, o local e o LOINC, em OBX-3, normalizando as unidades para UCUM, e codificando os tipos de amostra e organismos em SNOMED CT. Sem este mapeamento, os resultados não podem ser acompanhados entre laboratórios nem lidos por sistemas externos.
Mapeie os códigos de teste do laboratório para LOINC uma vez, numa tabela mantida, e envie ambos os códigos, local e LOINC, em OBX-3 (GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN). Normalize as unidades para UCUM. Tipos de espécime e organismos em SNOMED CT. O método está em Como mapear códigos de laboratório locais para LOINC; sem ele, os resultados não podem ser acompanhados ao longo do tempo entre laboratórios nem lidos por qualquer sistema externo.
Passo 5: a alternativa FHIR
A alternativa FHIR a uma interface laboratorial HL7 v2 utiliza um ServiceRequest para o pedido, uma Observation por analito com um código LOINC, quantidade UCUM, intervalo de referência e interpretação, e um DiagnosticReport que os agrupa com estado, executante, hora de emissão, conclusão e PDF. A entrega é feita através de escritas REST, um Bundle de transação por relatório, ou Subscrições FHIR.
Com FHIR, o pedido é um ServiceRequest, os resultados são Observations (um por analito, código LOINC, quantidade UCUM, referenceRange, interpretação) agrupados por um DiagnosticReport que transporta o estado, o executante, a hora de emissão, a conclusão e o PDF, com basedOn a apontar para o ServiceRequest. Correções são versões dos mesmos recursos com estado amended ou corrected. A entrega é feita através de escritas REST para o servidor FHIR do EHR, um Bundle de transação por relatório, ou Subscriptions. O guia HL7 v2-to-FHIR mapeia cada campo acima; muitos laboratórios oferecem agora ambos. Ver FHIR DiagnosticReport explicado e FHIR Observation explicado.
Passo 6: testes e entrada em funcionamento
Testar uma interface laboratorial antes da entrada em funcionamento significa executar pacientes sintéticos através de cada caso especial, comparar um dia de resultados paralelos entre o relatório do laboratório e o registo do EHR, verificar fusos horários e transições de horário de verão, verificar o tratamento de acusações de receção e repetição após uma interrupção, e acordar um procedimento de plantão para mensagens falhadas, utilizando o perfil Laboratory Testing Workflow da IHE como base.
Teste com pacientes sintéticos através de todos os casos do passo 3; compare um dia de resultados paralelos entre o relatório em papel ou PDF e o prontuário; verifique fusos horários e transições de horário de verão; valide o tratamento de ACKs e a repetição após uma interrupção; acorde um procedimento de plantão para mensagens falhadas. O perfil Laboratory Testing Workflow da IHE e as suites nacionais de conformidade fornecem uma base testada.
Falhas a ter em conta no design
As falhas contra as quais uma interface laboratorial deve ser projetada são resultados arquivados num encontro anterior, fusões de pacientes não aplicadas ao LIS, alterações de unidades após uma atualização de analisador que desviam tendências, resultados corrigidos que se sobrepõem sem um alerta, suscetibilidades de microbiologia anexadas ao organismo errado, e resultados de testes para os quais o EHR não tem código, desaparecendo numa fila de erros.
Resultados arquivados numa consulta anterior porque PV1 estava desatualizado; uma fusão (ADT A40) não aplicada ao LIS; uma alteração de unidade após uma atualização de analisador a deslocar silenciosamente as tendências; resultados corrigidos a sobrescrever sem alerta; suscetibilidades de microbiologia anexadas ao organismo errado; um laboratório a enviar resultados para um teste para o qual o EHR não tem código, que depois desaparecem numa fila de erros.
Em Anpheros
O conector de laboratório Anpheros aceita ORU^R01, CSV e JSON e produz Observations sob um DiagnosticReport com LOINC e UCUM, mantendo os códigos locais e o ficheiro original; o guia do programador sobre importar resultados de laboratório percorre o processo contra a sandbox gratuita.
Páginas relacionadas
- Mensagens de pedido HL7 v2 ORM e OML
- Mensagens HL7 v2 explicadas: ADT e ORU
- Como mapear códigos de laboratório locais para LOINC
- FHIR DiagnosticReport explicado
- Conector de laboratório: HL7 v2, CSV ou JSON para FHIR
- Motores de interface explicados
- Importar resultados de laboratório para FHIR (site do programador)
Fontes
- HL7 v2.5.1 ORU_R01 referência (Caristix)
- HL7 v2.5.1 segmento OBX (Caristix)
- Framework técnico IHE Laboratório (LTW)
- Guia de implementação HL7 v2-para-FHIR
- HL7 FHIR R4: DiagnosticReport
Perguntas frequentes
Qual versão HL7 uma nova interface de laboratório deve usar?
2.5.1 se ambos os lados a suportarem: tem SPM para espécimes e um tratamento de estado mais claro. Muitos laboratórios ainda usam 2.3.1, e a interface adapta-se ao lado mais antigo.
Como são os resultados correspondidos aos pedidos?
Pelo número do pedido do colocador (atribuído pelo EHR) e o número do pedido do preenchedor (atribuído pelo LIS), transportados em ORC-2/3 e OBR-2/3 tanto da resposta do pedido como do resultado. Se o EHR nunca registou o número do preenchedor, a correspondência volta ao número do colocador.
E se o laboratório não puder enviar códigos LOINC?
Mapeie os seus códigos locais para LOINC do seu lado, no motor ou no conector, e mantenha ambos. Insista que o sistema de códigos local é estável e que novos testes são anunciados.
O FHIR está pronto para interfaces de laboratório?
Sim para novas ligações, especialmente fora do hospital: ServiceRequest, Observation e DiagnosticReport cobrem pedidos e resultados na totalidade, e guias nacionais definem-nos. Dentro do hospital, o LIS e os analisadores falarão HL7 v2 durante anos.
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.
Grátis · 30 pacientes sintéticos · sem cartão

