¿Qué problemas tienden a surgir al trabajar con mensajes HL7?

Estoy probando un producto para empresas de atención médica, y estamos trabajando con mensajes HL7. Vi gente quejándose de otra pregunta sobre los problemas con HL7 pero sin mencionar detalles. ¿Alguien puede darme algunas ideas sobre qué problemas o clases de problemas deberíamos buscar específicamente?

Estamos utilizando algunas bibliotecas bien utilizadas para el análisis. Si los detalles sobre estos o lo que estamos haciendo serían útiles, hágamelo saber en los comentarios y, si puedo, agregaré a la pregunta.

testing parsing hl7 Ethel Evans
fuente

Respuestas:

Supongo que está tratando con HL7 v2.x

HL7 es voluntariamente extremadamente flexible. Eso tiene grandes ventajas pero también presenta desafíos. Una regla básica a tener en cuenta es que cada implementación será diferente. Si implementa el mismo producto en 2 entornos diferentes (2 hospitales, por ejemplo), la regla de intercambio de datos probablemente será diferente. Su producto debe estar listo para cumplir con esos requisitos ocultos si desea poder escalar la cantidad de interfaz HL7 con la que interactuará.

En la mayoría de los sistemas de salud que se ocupan de HL7, nos enfrentamos a esta lista parcial de desafíos comunes:

Cada sistema podría interpretar el significado de cada pieza de datos. También el contexto y los flujos de trabajo pueden influir en la semántica. Vi algunos sistemas que utilizan el número de cuenta (PID.18) o el número de visita (PV1.19) para identificar al paciente que cumple con algunos flujos de trabajo clínicos. Ese tipo de brecha semántica probablemente tendrá algunos impactos sobre cómo el sistema recibe estos datos.
Requerido vs. Opcional: Debido a que se puede intercambiar un dato para lograr varios objetivos en varios contextos diferentes, la mayoría de los segmentos y campos se documentan como opcionales en la documentación oficial (y algunos analizadores). Sin embargo, para satisfacer flujos de trabajo específicos, los productos sanitarios probablemente agregarían reglas de restricción de datos y relajarían algunos otros. La mayoría de las veces, es necesario realizar un análisis caso por caso para identificarlos.
Tablas: HL7 proporciona una lista de valores sugeridos para algunos campos. Por ejemplo, la lista de valores sugeridos para género es larga ... Obviamente, la mayoría de los sistemas no implementan los 6, pero ¿cuál es su estrategia de mapeo si recibe uno que no admite por adelantado?
Los segmentos y campos se pueden personalizar: la longitud del campo, los tipos de datos y otros atributos de definición se pueden personalizar. Debe asignarlo a alguna estructura de datos que conozca sin perder información importante.

jlmorin

www.caristix.com

jlmorin
fuente

Algunos problemas que he encontrado:

Algunas organizaciones pueden usar diferentes versiones de HL7, por lo que tendrá problemas de compatibilidad ("cross-walking"). Ciertamente te encontrarás con esto si te involucras en cualquier transferencia de datos entre organizaciones.
No existe un estándar semántico (para v2.x, creo que v3 puede haber comenzado a abordar esto), por lo que incluso si sabe qué datos deberían estar en un campo en particular, es posible que no sepa el significado exacto o la representación de esos bytes.
HL7 es un estándar no estándar. Es compatible con proveedores específicos Z-segmentsque son ampliamente utilizados y totalmente propietarios.
HL7 v2.x (muchos valores de x aún en uso en la naturaleza) es un formato no propietario de XML, por lo que necesitará un analizador HL7 para trabajar con él. (Esto, ya sabes que ya tienes una biblioteca de análisis HL7 que solo la incluye para otros)

SOL__
fuente

Lo peor de eso es la falta de semántica. Cuando incluso las personas que escriben el estándar dicen "bueno, podrías enviar X o Y, pero Z también es válido", sabes que tienes un problema. Lo que lo salva es que nadie, excepto el analizador, tiene que lidiar con toda la gama de opciones de HL7: todos se ocupan del pequeño subconjunto que reciben sus clientes. Significa que escribir un nuevo aceptador es un proceso de descubrimiento (que estoy pasando ahora) en lugar de un ejercicio de "implementar el estándar". Ah, y adivinar a qué opción debe enviar para tener el efecto deseado.

@ +1 para la respuesta, y con podría dar +1 para incluir información para personas que no sean OP (yo). @moz: buen punto sobre solo necesitar un pequeño subconjunto. Esa es precisamente nuestra situación. También está confirmando mi sospecha de que la comparación con los datos del cliente será clave.

Ethel Evans

@ethel y @moz, ese es exactamente el tipo de pensamiento que hace que lidiar con HL7 sea tan difícil, tómese el tiempo para hacer que sus programas sean lo más flexibles posible, HL7 es un lugar donde YAGNI no es aplicable de ninguna manera.

Peter Turner

De acuerdo, esto tiene sentido. No creo que nuestra aplicación cause problemas con YAGNI, ya que estamos planeando con anticipación expandir los tipos de mensajes HL7 que podemos usar para proporcionar valor. Sabemos que no sabemos lo que necesitaremos en el futuro.

Ethel Evans

Es por eso que soy fanático de usar las bibliotecas de código abierto (HAPI / NHAPI) al menos para el lado receptor. Mucho mejor tener un alto nivel "recibimos un mensaje HL7 válido pero no hemos escrito código para procesarlo" que "nuestro analizador falló porque no esperábamos ese mensaje". Desafortunadamente, todo el mundo comienza con un pequeño "simplemente enviamos X y recibimos Y", por lo que es mucho más simple piratear algo por un tiempo que extenderlo cada vez que llega un nuevo requisito hasta que finalmente se derrumba bajo el peso de la masa acumulada.

El primer problema es asegurarse de que todos sepan qué es HL7.

Es una forma de reemplazar los codificadores [médicos | de facturación | seguros] y ahorrar dinero a una [farmacia | banco | compañía de seguros].

Esa es la arruga además de todos los problemas normales en el desarrollo de software.

Alcance Creep
Especificaciones incompletas
Especificaciones de propiedad no válidas que "No se pueden cambiar"

Entonces, usted contacta a su [Farmacia | Banco | Compañía de Seguros] que quiere gastar todo el dinero que pueda de una interfaz HL7 a la instalación que utiliza su software. Su contrato es con la instalación, su contrato es con la farmacia, la [Farmacia | Banco | Compañía de seguros] no tiene idea de cómo funciona su software, la instalación no tiene idea de qué es HL7 y está molesto en la farmacia porque constantemente le digo que su software tiene errores.

Creo que el problema con HL7 es que se realiza principalmente a bajo precio. Es posible que HL7 3.0 nunca se materialice porque nunca monetizará.

Si va a "pagar por HL7", recuerde que también está pagando por HL [1-6]. Una interfaz SOAP no es HL7. Un analizador de mensajes HL7 no es HL7, tampoco es un generador de mensajes.

Peter Turner
fuente

HL7 es mucho más que solo para farmacias. La mayoría de las veces, HL7 se utiliza para conectar sistemas dispares, como un EMR, a un sistema de facturación.

Bill

Nuestro producto no está dirigido a farmacias, ni siquiera indirectamente, y la respuesta es muy parcial con poco apoyo para la respuesta.

Ethel Evans

@Ethel Agregaré algunas expresiones regulares, pero deberías ser más específico en tu pregunta. Hacemos más que las farmacias con nuestra implementación HL7 100% local, pero el motor principal del desarrollo siempre es la "gran farmacia", si otros pueden aprovechar una especificación ampliamente utilizada, que así sea.

Peter Turner

@ Peter: Trataré de ser más específico sobre por qué creo que esto no es útil. Primero, su cita resaltada parece muy sesgada y sin soporte. En segundo lugar, los elementos en su lista numerada son vagos o no agregan más allá de lo que otras respuestas han dicho más claramente. En tercer lugar, su escenario de ejemplo es muy específico y no se parece en nada al escenario que yo (y aparentemente otros) están tratando, lo que lo hace poco informativo. Cuarto, su afirmación de que HL7 se hace a bajo precio parece sesgada y sin respaldo. Quinto, no estoy haciendo "HL7", estoy trabajando con mensajes HL7, por lo que se pierde el punto del último párrafo.

Ethel Evans

@Ethel, ¿cómo demonios se supone que debo respaldar mis reclamos? No me beneficio para nada al hablar sobre HL7, lo que sí sé de mi experiencia en los últimos años trabajando con varios proveedores es que cuando alguien dice que quiere trabajar con mi software y para enviarles un "mensaje de prueba" para que puedan tener una idea de cómo se supone que debe verse, crearán una especie de ORM alrededor del mensaje y simplemente funcionará para eso. Esto no está bien. Si mi respuesta parece diferente a las demás, ciertamente no es porque no te estoy diciendo la verdad. HL7 es principalmente sobre el dinero.

Peter Turner