Red de usuarios y miembros de la comunidad HL7 de habla hispana.

2011-05-02

Cinco mitos de los proveedores de software, sobre el uso de HL7.

Estoy seguro que muchos de los lectores han escuchado algunas historias fantásticas donde el protagonista es HL7.  El peligro es creer que estas historias son ciertas.


Este artículo tiene por objeto evidenciar ciertos mitos que se han creado en torno al uso de HL7, que  algunos proveedores emplean de forma inescrupulosa, como parte de sus estrategias de venta, aprovechando el desconocimiento de sus clientes.

Estos mitos generan confusión entre la comunidad de usuarios, ofrecen una visión tergiversada y desestimulan el uso de los estándares HL7.  Por esta razón hemos decidido revelarlos públicamente.

Antes de empezar, quiero aclarar que este artículo no constituye ningún tipo de ataque a la industria de desarrollo de software para el sector salud.  Si su empresa a invertido recursos e investigación para implementar correctamente determinados casos de uso de estándares HL7 y sus productos cuentan con declaraciones de conformidad que los respaldan, no se sentirá afectado por algunos comentarios que puedan llegar a herir susceptibilidades.

Mito 1: 100% HL7.
Algunos proveedores de software aplicativo para instituciones hospitalarias, argumentan que sus productos y aplicaciones de software son 100% compatibles con los estándares HL7. ¿Qué hay de cierto en esto?.

Realidad: Habría que preguntar al proveedor implicado, a qué se refiere exáctamente cuando dice que sus productos son 100% HL7.

Si se refiere a que cumple correctamente una especificación de HL7 para soportar cierta interacción es posible que la afirmación sea válida, incluso podría soportar un buen número de especificaciones.  En cuyo caso recomendaría que usen expresiones más detalladas como: "100% compatible con la interacción POOR_IN200901UV para el rol de Placer".

Si se refiere a que su aplicación cumple con el 100% de las especificaciones normativas de HL7, habría que empezar a dudar de la veracidad de su afirmación.

HL7 es una familia de estándares informáticos para la salud, dentro de los cuales se destacan sus  estándares de interoperabilidad.

Solamente estándar HL7 v3 cuenta con más de treinta dominios que agrupan diversos casos de uso de interoperabilidad (registros médicos, laboratorio, salud pública, inmunización, banco de sangre, órdenes, farmacia, documentos electrónicos, etc) y cada uno de estos dominios incluye varias especificaciones de estructuras e interacciones de mensajes y documentos electrónicos.

Es tanta la cantidad de especificaciones de estándares HL7 que las aplicaciones de software y sistemas de información que han implementado HL7, por lo general soportan un conjunto de especificaciones, pero NO todas las disponibles.

Incluso en ciertos escenarios de casos de uso es difícil que una aplicación de software soporte todas las especificaciones HL7. Por ejemplo, es posible que un sistema LIS (Laboratory Information System) cuente con interfaces para intercambiar información (órdenes y/o resultados) con ciertos dispositivos analizadores  (hematología, bioquímica, uroanálisis, etc) de determinadas marcas y modelos, empleando mensajería HL7 v2.x.  En este caso, es posible declarar que el LIS emplea un conjunto especificaciones  para casos de uso de laboratorio clínico, de conformidad con los estándares HL7, sin embargo, esto no es suficiente para asegurar que dicho LIS se comunicará con cualquier dispositivo analizador empleando HL7 o que capaz de soportar todo tipo de interacciones HL7 dentro del contexto de un laboratorio clínico, como el intercambio de órdenes electrónicas (HL7 V3 OR R1) entre un hospital y el laboratorio o el envío de reportes de resultados de pruebas diagnósticas mediante documentos clínicos electrónicos (HL7 CDA R2).

En resumen, si es difícil asegurar que un sistema LIS soporta todas las especificaciones HL7 disponibles para el escenario de laboratorio clínico, será aún más difícil que un sistema de información clínica (CIS) o un sistema de información hospitalaria (HIS), soporte el 100% de especificaciones HL7.

Para asegurarse que especificaciones  tiene implementadas una aplicación de software, conviene solicitar al proveedor las declaraciones de conformidad correspondientes.  Ésta no es una garantía completa de que los estándares se empleen correctamente, pero servira como base para que un experto pueda realizar una auditoría de conformidad a partir de dichas declaraciones.

Conclusión: FALSO. El hecho de utilizar algunas especificaciones no implica que un sistema o aplicación de software tenga la capacidad de soportar todos los casos de uso de los estándares HL7.


Mito 2: HL7 es un protocolo de comunicaciones de equipos biomédicos.
Algunos proveedores de software aplicativo para instituciones hospitalarias, argumentan que HL7 es un protocolo que se limita al intercambio electrónico de datos con dispositivos biomédicos. ¿Qué hay de cierto en esto?.

Realidad: Muchos grandes proveedores de la industria de la salud han adoptado estándares HL7 para que sus dispositivos biomédicos puedan importar y exportar información en forma estándar.  Sin embargo, los estándares  HL7 no se limitan a este tipo de casos y su alcance abarca una gran cantidad de especificaciones que permiten la interoperabilidad entre sistemas de información y aplicaciones de software en contextos intrahospitalarios e interhospitalarios.

El hecho que una aplicación o un producto de software utilice HL7 únicamente para comunicarse con dispositivos biomédicos, no es motivo para que su proveedor asevere que los estándares HL7 se limitan a este tipo de casos.

Conclusión: FALSO. HL7 NO se limita únicamente al intercambio electrónico de datos con equipos biomédicos, su uso es mucho más extenso.

Mito 3: Aproximación a HL7.
Algunos proveedores de software aplicativo para instituciones hospitalarias, argumentan que sus productos y aplicaciones de software no utilizan exactamente HL7 sino una aproximación a HL7. ¿Qué hay de cierto en esto?.

Realidad: El argumento de utilizar aproximaciones a los estándares HL7 es equivalente a decir que “un gato es una aproximación de una liebre”.

Conviene aclarar que cuando se emplean estándares HL7 es necesario ajustarse a  las especificaciones, si no hay conformidad plena, no será posible establecer interoperabilidad estándar con otros sistemas de información.

Conclusión: FALSO. Si se decide emplear una especificación, es necesario implementarla de conformidad con los estándares.

Mito 4: Empleo una librería que hace que HL7 funcione plenamente en mi aplicación de software.
Algunos proveedores de software aplicativo para instituciones hospitalarias, argumentan que sus productos y aplicaciones de software utilizan determinadas librerías o plataformas que permiten que sus productos sean 100% compatibles con HL7. ¿Qué hay de cierto en esto?.

Realidad: Este mito tiene una relación cercana con el mito número 1.

Los principales proveedores de la industria informática como IBM, Oracle, Microsoft, etc, cuentan con plataformas de desarrollo y librerías que facilitan enormemente la implementación de interacciones y casos de uso de interoperabilidad, de acuerdo a las especificaciones de estándares HL7.

Las principales plataformas informáticas que cuentan con librerías HL7 (WebSphere, Healthcare Transaction Base, Biz Talk Sever, etc), son excelentes herramientas (algunas mejores que otras), pero como toda herramienta, el éxito del trabajo realizado dependerá de la habilidad del artesano y de la materia prima que se esté empleando.

Estas plataformas o librerías ofrecen funcionalidades para el uso de DataTypes HL7, uso de tecnología XML para el desarrollo de plantillas (templates) de mensajes HL7 v3, validación sintáctica, implementación de especificaciones de transporte, controles, eventos disparadores, automatización de flujos de trabajo, etc.

Aquellas aplicaciones de software que emplean este tipo de plataformas, pueden implementar especificaciones HL7 con mayor precisión y en menor tiempo que quienes no las usan.  Sin embargo, es necesario analizar y desarrollar cada caso e interacción de acuerdo al contexto en que se vaya a emplear.

Afirmar que por el hecho de emplear una plataforma o librería, automáticamente una aplicación puede soportar cualquier caso de uso de HL7, sería equivalente a asegurar que por el hecho de utilizar un determinado entorno de desarrollo (IDE) las aplicaciones se desarrollan por sí solas.

Conclusión: FALSO.  Las plataformas y librerías informáticas hacen gran parte de trabajo, pero no todo el trabajo.

Mito 5: Estoy afiliado a HL7 y por lo tanto mis productos cumplen con las especificaciones HL7.
Algunos proveedores de soluciones informáticas para el sector salud son miembros de HL7 intencional o de algún capítulo nacional de HL7, y por lo tanto argumentan que sus productos cumplen con las especificaciones HL7. ¿Qué hay de cierto en esto?.

Realidad: Empleando una analogía, el hecho de matricularse en una escuela de artes marciales no  es suficiente para que una persona casi de inmediato pueda asegurar: “ ¡ I Know Kung Fu !”.

La membresía a HL7 concede una serie de derechos como el acceso a las especificaciones de los estándares, participar en grupos de trabajo, aportar y decidir en el desarrollo de especificaciones y nuevas versiones, obtener descuentos en libros, capacitación y actividades de la organización Health Level Seven Inc, etc.

Entre los derechos de los miembros afiliados a HL7 no se menciona que automáticamente sus productos adquieran la conformidad de uso de las especificaciones de sus estándares.

Algunos proveedores inescrupulosos se afilian a HL7 para hacer creer a sus potenciales clientes que han implementado estándares HL7 en sus productos.

Conclusión: FALSO, el ser miembro no es ninguna garantía de que un proveedor haya impementado correctamente los estándares HL7 en sus productos.

Si usted o su organización están a punto de adquirir una aplicación de software o sistema de información que emplee estándares HL7, espero que este artículo haya sido de utilidad para tomar una buena decisión.

Recomiendo complementar esta lectura con el artículo: Cinco mitos de las organizaciones de salud, sobre el uso de HL7.

Licencia Creative Commons

4 comentarios:

  1. Excelente artículo. Respecto de las librerías que pueden facilitar el trabajo de algunas aplicaciones si bien es cierto que es prácticamente imposible hacer una librería multifuncional si que se puede conseguir que una aplicación concreta formule un mensaje correcto en base al estándar HL7 para un caso de uso concreto. Entonces si se validara dicha funcionalidad se podría decir que se cumple con un caso de uso concreto del estándar HL7 no?

    ResponderEliminar
    Respuestas
    1. Eduardo:
      En cuanto al uso de HL7 V2.x, debido a que los mensajes emplean una sintaxis particular (segmentos de texto que emplean el símbolo pipe como delimitador de campos), existen liberías disponibles facilitar la construcción de mensajes (como HAPI).

      Plataformas EBS como IBM WebSphere MQ, TIBCO, Oracle OMF, BizTalk, etc, y motores de interoperabilidad como Mirth Connect, cuentan con librerías o extensiones para crear conectores HL7 V2.x.

      En el caso de las especificaciones "HL7 V3" y "HL7 V2 XML", es el uso de los schemas XML respectivos, los que facilitan la construcción de mensajes conformes al los estándares. Ésto facilita la implementación, al reducir la dependencia de librerías especializadas y emplear las librerías XML disponibles para cada lenguaje de programación.

      Respecto a tu pregunta, para emitir una declaración de conformidad, más que evaluar la funcionalidad, en términos generales se debe cumplir la siguiente lista de chequeo:

      1) Capacidad, para generar o leer instancias HL7 V3 (mensajes o documentos electrónicos), de acuerdo al rol (placer o filler), que desempeña en el escenario de interoperabilidad.
      3) Conformidad de la sintaxis de los mensajes y/o documentos electrónicos, empleando los schemas XML que hacen parte de las especificaciones HL7 V3 o de los Schemas XML de los refinamientos locales de los estándares.
      4) Conformidad semántica de los mensajes (contenido, uso de vocabularios controlados, etc).
      5) Soporte del intercambio electrónico de los mensajes, a través de un (o varios) protocolo(s) de transporte deteminado(s).
      6) Conformidad sitáctica y semántica de los ACK.
      7) Capacidad para soportar las interacciones de mensajes, realizando una batería de múltiples pruebas.

      Espero que mi respuesta te haya sido útil.

      Eliminar
  2. buena información, de esta manera aclara muchas dudas respecto al uso de estos servicios tanto del dominio como del hosting, solo es cuestión de saber que proveedor nos brinda la mejor garantía y servicio, lo leí en este blog www.dinerea.com/como-comprar-hosting-web-wordpress/

    ResponderEliminar