Quais problemas tendem a surgir ao trabalhar com mensagens HL7?

Estou testando um produto para empresas de assistência médica e estamos trabalhando com mensagens HL7. Vi pessoas gemendo em outra pergunta sobre os problemas com o HL7, mas sem mencionar detalhes. Alguém pode me dar algumas idéias de quais questões ou classes de problemas devemos procurar especificamente?

Estamos usando algumas bibliotecas bem usadas para a análise. Se detalhes sobre isso ou o que estamos fazendo forem úteis, informe-nos nos comentários e, se possível, acrescentarei à pergunta.

testing parsing hl7 Ethel Evans
fonte

Respostas:

Presumo que você esteja lidando com o HL7 v2.x

O HL7 é voluntariamente extremamente flexível. Isso tem grandes vantagens, mas também apresenta desafios. Uma regra básica a ter em mente é que cada implementação será diferente. Se você implantar o mesmo produto em 2 ambientes diferentes (2 hospitais por exemplo), a regra de troca de dados provavelmente será diferente. Seu produto deve estar pronto para atender a esses requisitos ocultos, se você quiser escalar o número de interfaces HL7 com as quais ele irá interagir.

Na maioria dos sistemas de saúde que lidam com o HL7, enfrentamos esta lista parcial de desafios comuns:

Cada sistema pode interpretar o significado de cada dado. Além disso, o contexto e os fluxos de trabalho podem influenciar a semântica. Vi alguns sistemas usando o número da conta (PID.18) ou o número da visita (PV1.19) para identificar o paciente como compatível com alguns fluxos de trabalho clínicos. Esse tipo de lacuna semântica provavelmente terá alguns impactos sobre como o sistema recebe esses dados.
Necessário versus opcional: como uma parte dos dados pode ser trocada para atingir vários objetivos em vários contextos diferentes, a maioria dos segmentos e campos é documentada como opcional na documentação oficial (e em alguns analisadores). No entanto, para satisfazer fluxos de trabalho específicos, os produtos de saúde provavelmente adicionariam regras de restrições de dados e relaxariam outras. Na maioria das vezes, uma análise caso a caso precisa ocorrer para identificá-los.
Tabelas: O HL7 fornece uma lista de valores sugeridos para alguns campos. Por exemplo, a lista de valores sugerida para o gênero é de seis longas ... Obviamente, a maioria dos sistemas não implementa todas as seis, mas qual é a sua estratégia de mapeamento se você receber uma que não oferece suporte inicial?
Segmentos e campos podem ser personalizados: Comprimento do campo, tipos de dados e outros atributos de definição podem ser personalizados. Você precisa mapeá-lo para alguma estrutura de dados que você conhece sem perder informações importantes.

jlmorin

www.caristix.com

jlmorin
fonte

Alguns problemas que encontrei:

Algumas organizações podem usar versões diferentes do HL7, portanto, você terá problemas de compatibilidade ("cross-walking"). Certamente você encontrará isso se se envolver em qualquer transferência de dados interorganizacionais.
Não existe um padrão semântico (para a v2.x, acho que a v3 pode ter começado a resolver isso), portanto, mesmo se você souber quais dados devem estar em um campo específico, talvez não saiba o significado exato ou a representação desses bytes.
HL7 é um padrão não padrão. Ele suporta específicos do fornecedor, Z-segmentsque são amplamente utilizados e totalmente proprietários.
O HL7 v2.x (muitos valores de x ainda em uso na natureza) é um formato proprietário não XML, portanto, você precisará de um analisador HL7 para trabalhar com ele. (Você já sabe que já possui uma biblioteca de análise HL7, incluindo-a para outras pessoas)

G__
fonte

O pior deles é a falta de semântica. Quando até as pessoas que escrevem o padrão dizem "bem, você pode enviar X ou Y, mas Z também é válido", você sabe que tem um problema. O que economiza é que ninguém, exceto o pessoal do analisador, tem que lidar com toda a gama de opções HL7 - todo mundo lida com o pequeno subconjunto que é realmente recebido por seus clientes. Significa que escrever um novo aceitador é um processo de descoberta (pelo qual estou passando agora), e não um exercício de "implementar o padrão". Ah, e adivinhar em qual opção você precisa enviar para obter o efeito desejado.

@ +1 para a resposta, e com eu poderia dar +1 para incluir informações para outras pessoas que não o OP (eu). @moz - bom argumento sobre a necessidade de apenas um pequeno subconjunto. Essa é precisamente a nossa situação. Você também está confirmando minha suspeita de que a comparação com os dados do cliente será fundamental.

Ethel Evans

@ethel e @moz, esse é exatamente o tipo de pensamento que torna tão difícil lidar com o HL7; por favor, dedique um tempo para tornar seus programas tão flexíveis quanto possível, o HL7 é um lugar onde o YAGNI não é aplicável.

Peter Turner

Ok, isso faz sentido. Não acho que nosso aplicativo cause problemas com o YAGNI, pois estamos planejando expandir os tipos de mensagens HL7 que podemos usar para fornecer valor. Sabemos que não sabemos o que precisaremos no futuro.

Ethel Evans

É por isso que sou fã de usar as bibliotecas de código aberto (HAPI / NHAPI) pelo menos para o lado receptor. Muito melhor ter um nível alto ", recebemos uma mensagem HL7 válida, mas não escrevemos o código para processá-la", do que "nosso analisador falhou porque não esperávamos essa mensagem". Infelizmente, todo mundo começa pequeno "apenas enviamos X e recebemos Y", então é muito mais simples hackear algo juntos, para depois estendê-lo toda vez que um novo requisito chega até que, eventualmente, ele cai sob o peso do lixo acumulado.

A primeira questão é garantir que todos saibam o que é o HL7.

É uma maneira de substituir os codificadores [médicos | faturamento | seguro] e economizar um dinheiro [farmácia | banco | companhia de seguros].

Essa é a ruga de todos os problemas normais no desenvolvimento de software.

Oportunista
Especificações incompletas
Especificações proprietárias inválidas que "Não podem ser alteradas"

Então, você entra em contato com a [Farmácia | Banco | Companhia de Seguros] que deseja economizar todo o dinheiro que pode desde uma interface HL7 até a instalação que usa o seu software. Seu contrato é com a instituição, o contrato é com a farmácia, a [Farmácia | Banco | Companhia de Seguros] não tem idéia de como o seu software funciona, a instituição não tem idéia do que é o HL7 e você é marcado na farmácia porque eles constantemente lhe digo que seu software está com erros.

Acredito que o problema com o HL7 é que ele é feito principalmente de forma barata. O HL7 3.0 pode nunca se materializar, porque nunca gerará receita.

Se você vai "pagar pelo HL7", lembre-se de que está pagando pelo HL [1-6] também. Uma interface SOAP não é HL7. Um analisador de mensagens HL7 não é HL7, nem um gerador de mensagens.

Peter Turner
fonte

O HL7 é muito mais do que apenas para farmácias. Na maioria das vezes, o HL7 é usado para conectar sistemas diferentes, como um EMR, a um sistema de cobrança.

Bill

Nosso produto não é direcionado para farmácias, mesmo que indiretamente, e a resposta é muito tendenciosa, com pouco apoio para a resposta.

Ethel Evans

@ Ethel, adicionarei algumas expressões regulares, mas você deve ser mais específico em sua pergunta. Fazemos mais do que farmácias com nossa implementação de HL7 100% desenvolvida em casa, mas o principal motor do desenvolvimento é sempre o "grande mercado", se outros puderem tirar proveito de uma especificação amplamente usada, que assim seja.

Peter Turner

@ Peter: Vou tentar ser mais específico sobre o motivo pelo qual acho que isso não é útil. Primeiro, sua cotação destacada parece altamente tendenciosa e sem suporte. Segundo, os itens da sua lista numerada são vagos ou não acrescentam além do que as outras respostas disseram mais claramente. Terceiro, seu cenário de exemplo é altamente específico e não se parece em nada com o cenário com o qual eu (e aparentemente outros) estamos lidando, tornando-o pouco informativo. Quarto, sua afirmação de que o HL7 é feito de forma barata parece tendenciosa e sem suporte. Quinto, não estou fazendo "HL7", estou trabalhando com mensagens HL7, portanto, o ponto do último parágrafo está perdido.

Ethel Evans

@ Ethel, como diabos devo apoiar minhas reivindicações, não me beneficio com o HL7, o que sei da minha experiência nos últimos anos trabalhando com vários fornecedores é que, quando alguém diz que quer trabalhar com meu software e enviar a eles uma "mensagem de teste" para que eles possam entender como deve ser, criarão algum tipo de ORM em torno da mensagem e funcionará apenas para isso. Isto não é bom. Se minha resposta parece diferente das outras, certamente não é porque não estou lhe dizendo a verdade. HL7 é principalmente sobre o dinheiro.

Peter Turner