¿El ocaso de HL7 V3?

Durante años me he sido un firme defensor de HL7 V3 y en nuestro equipo hemos trabajado duro en implementaciones que utilizan esta versión de estándares HL7, pero hoy debo admitir que la mensajería HL7 V3 ha entrado en el ocaso. 

Esta NO es la posición oficial en Health Level Seven, quien ha realizado un gran esfuerzo en el desarrollo de HL7 V3, construyendo con la colaboración de expertos internacionales, un estándar mucho más robusto y con ventajas tecnológicas sobre su predecesor HL7 V2.x.

A pesar de ello, las dificultades de implementación de HL7 V3 y los escasos resultados en su adopción (respecto a las altas expectativas), son evidentes desde hace varios años y algunos artículos de expertos como Grahame Grieve (HL7 needs a fresh look because V3 has failed) o Wes Rishel  (Lessons From the Putative Failure of HL7 V3), eran evidencia de su decadencia en el mercado.

El informe de Gartner Group acerca del hiper ciclo para las tecnologías y estándares de cuidado de la salud del año 2009, declaró a la mensajería HL7 V3 como obsoleta, convirtiéndose este diagnóstico en evidencia del declive de esta especificación.  La siguiente imagen hace parte de dicho informe.

Haga click sobre la imagen para verla ampliada

La obsolescencia de HL7 V3 no es un fracaso.

Algunos podrían suponer que el desuso de HL7 V3 es un fracaso, sin embargo, el desarrollo de ésta versión de estándares HL7 codujo a importantes avances para la interoperabilidad clínica, entre los cuales se desatacan:

CDA®: La especificación HL7 CDA® R2 (ISO/HL7 27932: 2008) es sin duda un éxito de HL7 V3 y es uno de los estándares informáticos más importantes desarrollados por Health Level Seven Inc.

CDA® ha facilitado una arquitectura que permite construir documentos clínicos electrónicos consistentes,  a partir de sus equivalentes funcionales (registros clínicos en formatos impresos y digitales); convirtiéndose en uno de los estándares fundamentales para el uso compartido de la historia clínica electrónica.

Gracias a sus características tecnológicas y a la estrategia de difusión del grupo de trabajo de HL7 CDA® R2, este estándar cuenta hoy en día con múltiples e importantes implementaciones a nivel mundial, siendo adoptado en forma intensiva por la industria de desarrolladores de TI para el sector salud.

En el diagrama de Hiper Ciclo de Gartner Group, puede observarse cómo CDA® se ubica en la ladera de esclarecimiento, muy cerca de alcanzar la meseta de productividad. 

CCD (Continuity of Care Document): Esta especificación de plantilla de HL7 CDA®  R2 para la adaptar documentos clínicos electrónicos HL7 al estándar CCR (Continuity of Care Record© - norma ASTM E2369-05), ha comenzado a ser ampliamente implementada en los Estados Unidos y en consecuencia muchos desarrolladores de TI para el sector salud han comenzado a adoptarla en diferentes países.

En el diagrama de Hiper Ciclo de Gartner Group, puede observarse cómo CCD se ubica en un segmento de la curva, donde la propuesta de valor comienza a ser más clara, pero con éxitos selectivos. 

RIM: La especificación HL7 V3 RIM R1 (ISO/HL7 21731: 2006), se creó como un modelo abstracto de referencia que asegura la integridad semántica en el proceso de refinamiento de dominios y mensajes HL7 V3.

El grupo de trabajo de HL7 V3 RIM R1 logró abstraer la complejidad del sector salud, hasta convertirlos en un modelo que cuenta con seis clases fundamentales (actos, relaciones entre actos, participaciones, roles, relaciones entre roles y entidades), que facilitan la descripción, de las situaciones asistenciales del sector salud, en términos informáticos.

A pesar de no ser una herramienta pragmática para los implementadores, el RIM aporta un diagrama de clases fundamental para el modelamiento informático de la realidad del sector salud.

El uso de XML como tecnología de implementación: Si bien XML tardó en convertirse en un lenguaje informático de uso intensivo en los países Iberoamericanos, la decisión temprana de utilizarlo como tecnología de implementación de HL7 V3 fue un acierto tecnológico importante.

En la actualidad, prácticamente todos los lenguajes de programación cuentan con librerías para el uso de XML; XML cuenta además con una amplia familia de tecnologías estándar para facilitar su procesamiento (transformaciones XSLT, XLink, Xpath, XQuery, XML Schema, Schematron, etc); a partir de XML se han desarrollado una gran cantidad de dialectos para diversos usos como formatos de documentos electrónicos (ODF, XPS, DOCX, etc), imágenes y gráficos (SVG), sintaxis de estándares de interoperabilidad (HL7 v3, XBRL, GEL-XML, OasisLegal, EDIFACT, etc), documentos de hipertexto para publicación web (XHTML), comunicaciones (XMLRCP, SOAP, etc), etc.

Si bien, la falta de experiencia de los implementadores en el uso de XML parece haber dificultado en un principio la adopción de HL7 V3, es indudable que el haberlo elegido como tecnología, fue el camino correcto.

El uso intensivo de vocabularios controlados: Una de las características principales de HL7 V3 es el énfasis en el uso de vocabularios controlados internacionales (LOINC, CIE10, CIAP-2, SNOMED CT, etc).

Si bien, esta condición se convirtió en una piedra en el zapato para su implementación, HL7 V3 contribuyó a que los desarrolladores de TI para el sector salud y los organismos locales de dirección del sector salud en Iberoamérica, reconocieran la importancia del uso intensivo de vocabularios controlados, para facilitar la interoperabilidad semántica.

Actualmente el uso de SNOMED CT, en implementaciones de CDA® y CCD, ha significado un enorme avance para facilitar la interoperabilidad semántica.  A este respecto, el HIBA ha trabajado enormemente en los últimos años en la adopción de SNOMED CT en el contexto Iberoamericano.

¿Cuáles son las causas del declive de HL7 V3?

Si HL7 V3 condujo a importantes avances para la interoperabilidad clínica y cuenta con grandes aciertos como CDA®, CCD, RIM, el uso de XML y de vocabularios controlados, ¿por qué su aparente obsolescencia llegó antes que la de su antecesor HL7 V2.x?.

Mi percepción al respecto es que el desuso de HL7 V3 no se debe a sus problemas técnicos, sino a las barreras que había que sortear para su implementación y a una estrategia insuficiente para su adopción intensiva.

Considero que las barreras para la implementación fueron:

• Falta de experiencia de los implementadores en el uso de XML, sobre todo en Iberoamérica.

• Falta de experiencia de los implementadores en proyectos de interoperabilidad inter-organizacional (metodologías, protocolos de transporte, etc).

• La estructura de los mensajes HL7 V3 en sintaxis XML es compleja y requiere capacitación para su comprensión.

• La documentación de las especificaciones es compleja, su uso no es intuitivo y requiere entrenamiento para ser empleado.

• Las guías de implementación internacionales no son suficientemente claras.

• El contenido semántico no procesable en las estructuras de los mensajes, es elevado, en comparación con la carga útil contenida en los mismos.

• Las especificaciones universales, requieren un proceso de refinamiento y localización, para construir plantillas de mensajes que se adapten a las necesidades reales de un contexto específico en un país o región.

• Si bien el RIM fue un gran acierto, era necesario un profundo conocimiento y experiencia en esta especificación, para refinar plantillas (templates) semánticamente correctas.

• Estos procesos de refinamiento, requieren que los canales de conexión desarrollados sobre herramientas de software middleware (librerías, plataformas ESB y motores de interoperabilidad) sean adaptados para el uso de cada plantilla.

• Lo anterior, supone un desbalance a favor de los modeladores de las especificaciones, sobre las necesidades y el pragmatismo que requieren los implementadores.

• La ausencia de elementos para extensiones, dificultaba el desarrollo de plantillas que cumpliesen con los requerimientos de los contextos locales.

Por otra parte, considero las siguientes fallas en la estrategia:

• El lanzamiento de HL7 V3 generó muchas expectativas y tomó demasiado tiempo el comenzar a satisfacer las necesidades reales del mercado.

• El desarrollo de la mensajería HL7 V3 se centró principalmente en las necesidades y características del mercado estadounidense y no prestó suficiente atención a sus afiliados internacionales.

• El proceso de construcción de especificaciones es lento y requiere varios años para que un dominio alcance el estatus normativo.

• Las acciones de capacitación masiva tardaron en llegar al mercado. 

• Salvo excepciones en algunos países, el trabajo de los afiliados internacionales en la localización de estándares ha sido insuficiente.

• El apoyo y orientación de Health Level Seven Inc a sus afiliados internacionales, en los procesos de localización ha sido insuficiente.

• HL7 V3 fue liberado, pocos años después de que el mercado comenzase a implementar HL7 V2.3 en forma intensiva, lo cual significaba una nueva inversión en el mediano plazo, para adaptase a la nueva versión de los estándares.

Todas estas situaciones concomitantes, aceleraron decadencia de HL7 V3.

¿Es posible revertir la obsolescencia de HL7 V3?

Técnicamente, opino que una opción habría sido el re-enfoque en el desarrollo de plantillas (template project), junto a una estrategia de adopción y localización apoyada en los afiliados internacionales.

Como parte de esta estrategia  debían haberse desarrollado schemas XML para las plantillas locales, los cuales deberían ser refinados a partir de los schemas universales normativos de HL7 V3. Estos artefactos, junto a las guías respectivas, habrían proporcionado herramientas pragmáticas para la implementación, acelerando la adopción de las especificaciones en diferentes partes del mundo.

Algunos miembros de los grupos de trabajo de HL7, creen que es posible un ajuste de HL7 V3, y mantienen  la esperanza de que algunos proyectos gubernamentales de construcción de redes de interoperabilidad en salud elijan esta versión de los estándares HL7.

Sin embargo, estos proyectos tendrían que soportar procesos de refinamiento y localización, que pueden resultar demorados y costosos.

El uso de plataformas ESB (IBM WebSphere MQ, Oracle OMF, TIBCO, Microsoft BizTalk, Mule ESB, Intel SOA Express Way, etc) y motores de interoperabilidad (Mirth Connect, Interfaceware Iguana, HL7 Connect, etc), acelerarían la estrategia de adopción de HL7 V3, solucionando varios de los inconvenientes técnicos de la interoperabilidad.

A pesar de que existen alternativas para salvar a HL7 V3, el esfuerzo y el tiempo necesarios para lograrlo y cambiar la percepción de la comunidad de usuarios HL7, serían superiores al esfuerzo necesario para enfocarse en una nueva alternativa.

En su artículo "Renovate HL7 version 3", Rene Spronk, evidencia la necesidad de mejorar ciertas características de HL7 V3, para mejorar su usabilidad y para ello plantéa tres principios clave: A) Enfocarse en mejorar aspectos de reutilización de elementos (Añadir una capa de elementos reutilizables, Incrementar la reutilización del formato de conexión y Cambiar los artefactos publicados por lo que se pueden utilizar directamente para el MDD utilizando herramientas estándar.); B) Renovar HL7 v3 moviendo todo para CDA R3; C) Innovar moviendo todo para FHIR y cesar el desarrollo de HL7 v3.

Por mi parte, creo que es oportuno comenzar a apostar a la próxima generación de estándares HL7 que habrán de heredar a HL7 V3.

¿Quién heredará a HL7 V3?

Claramente, su ilustre hija CDA®, junto a su nieto CCD, heredarán los aciertos de HL7 V3, posicionándose como las principales especificaciones normativas de documentos electrónicos de salud.

Sin embargo, la posición respecto a las especificaciones de mensajería electrónica es aún incierta.

Es evidente que HL7 V2.x continuará desarrollándose para atender las necesidades de las implementaciones actuales, a pesar de ello, ni sus nuevas versiones, ni la especificación de codificación de sintaxis XML para HL7 V2.x (HL7 V2 XML, R2), se convertirán en la próxima generación de estándares HL7.

A mi modo de ver, sin ser un hijo de HL7 V3, pero habiendo aprendido de los aciertos y dificultades de ésta, FHIR® se convertirá en su heredera como la nueva y principal especificación de mensajería electrónica de los estándares HL7.

El informe de Gartner Group acerca del hiper ciclo para las tecnologías y estándares de cuidado de la salud del año 2013, ubica a FHIR® en la curva de ascenso, así que habrá que seguir cuidadosamente su evolución.

Ver documento: Hype Cycle for Healthcare Provider Technologies and Standards, 2013

¿Qué ocurre con quienes han adoptado HL7 V3?

Si su empresa u organización ya decidió emplear HL7 V3, por favor no entre en pánico y tenga en cuenta lo siguiente:

• Si ya ha resuelto algunos casos de uso de interoperabilidad empleando HL7 V3, ya está familiarizado con muchos aspectos de los proyectos de Health Information Exchange (ha identificado la carga útil de sus mensajes, ha elegido un protocolo, características de transporte y seguridad, ya emplea XML y cuenta con una metodología). Esto es un enorme acierto.

• Tenga en cuenta que a pesar de que Gartner Group haya declarado su obsolescencia en el mercado, HL7 V3 aún es útil y es un estándar tecnológicamente robusto y bien diseñado.

• Las necesidades de interoperabilidad de su organización no pueden esperar hasta que una nueva mejor alternativa se haya desarrollado y utilizar una solución estándar siempre es una mejor alternativa que una solución Ad hoc.

• Tendrá suficiente tiempo para disfrutar la vida útil de sus interfaces, ya que por lo pronto no hay muchas alternativas y la madurez de la nueva generación de estándares de mensajería electrónica de HL7 tardará en llegar al menos cinco (5) años.

• No estará solo, ya que aún hay suficientes grupos de trabajo construyendo especificaciones de dominios y mensajes HL7 V3 y cada día hay más profesionales capacitados en su uso.

• Cuando tenga que cambiar a la nueva versión de HL7, los mapeos sobre plataformas ESB y motores de interoperabilidad, se encargarán de facilitarle el trabajo de migración.

Mi recomendación es que consulte a un experto para que apoye su proceso de adopción de HL7 V3, para hacerlo más fácil.

Conclusión:

HL7 V3 es otro ejemplo de que no siempre la mejor tecnología es aquella que logra el favor del mercado y que muchas veces la estrategia correcta vence al más apto.

Imagen 1: Ver fuente.
Imagen 2: Ver fuente.
Imagen 3: Ver fuente.
Imagen 4: Fuente original - el autor.