2009-04-22 22 views
25

Búsqueda de una biblioteca o marco que proporcionaría un modelo de objetos, análisis, validación, etc.HL7 para .NET

La idea sería ser capaz de girar un nuevo objeto de tipo HL7 v2 o v3 . Entonces, quizás lo llame tipo de mensaje ORU_R01 o ADT, o ORM.

No sería la vida grande si hemos sido capaces de hacer algo como esto:

HL7V2 myMessage = new HL7V2(); 
myMessage.Type = V2MsgTypes.ORU_R01; 
myMessage.TryParse(someHL7_string); 

if (myMessage.IsValid) 
{ 
    //do some work 
    //maybe access the PID segment 
    if (myMessage.Patient.Names.FamilyName =="Johnson") 
    { 
    //do more work 
    } 
} 

Respuesta

28

¿Quieres nHAPI lo utilicé en un proyecto previamente, y funcionó muy bien. El hecho de que es de código abierto también salvó mi tocino, ya que una de las fuentes de entrada no seguía exactamente la especificación HL7, así que tuve que hackear la fuente un poco para hacer que el analizador de nHAPI permitiera esos mensajes (ya que no podía cámbialos).

+2

El problema con nHAPI es que asume un sabor de cualquier mensaje dado para una "versión HL7" en particular. La realidad de HL7 es que diferentes países tienen diferentes definiciones de HL7 (por ejemplo, los mensajes REF australianos son diferentes a los EE. UU.) Y que dentro de un país, diferentes laboratorios de patología tendrán su propio sabor de un mensaje ORU 2.3.1. Algunos países ni siquiera cambian el número de versión. nHAPI hace que sea difícil tener definiciones concurrentes. Un mejor enfoque quizás sea abstraerse de formatos EDI como HL7 y usar XML; XSD y XSLT en su lugar – MickyD

+1

Ese es un argumento válido, aunque tal vez la mejor respuesta es mejorar nHAPI, ya que el objetivo de nHAPI es hacer esa misma abstracción del formato EDI y convertirlo en un modelo de objetos. También se podría argumentar que los implementadores de las diversas aplicaciones HL7 deberían seguir mejor el estándar, ya que ese es el verdadero problema subyacente. Dado que eso no sucederá, mejorar el.La abstracción de NET me parece una mejor solución que crear una nueva. –

+1

Quizás. Es difícil obtener una velocidad decente con las bibliotecas de códigos EDI porque una corrección de errores o cumplimiento de algún mensaje oscuro de un laboratorio generalmente significa un cambio en el código en alguna parte (copiar y pegar una porción de nHAPI por ejemplo) y enviar una solución. Los sistemas EAI son un poco más fáciles porque todo lo que necesitas es un nuevo artefacto como XSLT, algo con lo que incluso podría llegar IT (por ejemplo, BizTalk, que te servirá para nada, que es bastante agradable). Ah ... pero estoy de acuerdo contigo y desearía poder despertar en un universo donde las instalaciones realmente se apegan a las normas :) – MickyD

0

Orion Helth tiene un kit de herramientas llamado Symphonia que hace algo similar. También hay juego de herramientas Chameleon de Interfaceware que hace lo mismo.

6

He usado nHAPI también y funciona muy bien. Sin embargo, es posible que tengas que tener cuidado con algún comportamiento peculiar para escapar de los personajes especiales. También tuve que hackear manualmente la cadena HL7 para actualizar algunos campos que eran inaccesibles utilizando el modelo de objetos.

0

yo sólo encontré con este producto, así:

Managed Code Objects for Visual Studio .Net

Desde su página web:

Un Visual Studio .Net HL7 biblioteca de clases DLL diseñado para permitir a los desarrolladores de software para proporcionar HL7 Integración HL7 para sus soluciones existentes de forma económica, rápida y confiable.

+1

_ [Su respuesta está en otro castillo: ¿cuándo una respuesta no es una respuesta?] (Http://meta.stackexchange.com/questions/225370/your-answer-is-in-another-castle-when-is-an-answer-not-a-answer) _. Considere editar su respuesta para contener un resumen del artículo al que apunta el enlace. – MickyD

0

Chris Patterson tiene una biblioteca para HL 7 manipulación 2.x llamada Machete que es bastante buena. https://github.com/phatboyg/Machete

NHapi está bien, pero tiene un rendimiento bajo en mi experiencia.