HL7 normalizando la comunicacion en salud

Hablar del estándar HL7 es difícil de comprender y utilizar, no solo por su complejidad estructural (ya que está formado por varios estándares), si no porque existen pocos materiales de aprendizaje y capacitación en español. Para este artículo vamos a concentrarnos en el modelo de referencia de HL7 v3, en el modelo de documentación clínica CDA, y en aspectos conceptuales a destacar y/o criticar de forma constructiva para ayudar a quienes encaran un proyecto usando HL7.

¿Buscas capacitación en HL7? Encuéntrala en CaboLabs

Introducción

Health Level Seven (HL7) no es un estándar en sí, si no que es un conjunto de estándares cuyo principal objetivo es especificar mensajería para la comunicación  de información clínica, demográfica y financiera, entre sistemas informáticos. Existen algunos estándares dentro de HL7 que tienen otros focos, pero la mensajería es uno de los aspectos más fuertes de HL7.

HL7 tiene su origen en los EEUU, y sus estándares reflejan el modelo de atención en ese país. Por ejemplo, en su modelo de referencia, junto con la información clínica se encuentra la información para facturación. Igualmente, hoy en día HL7 tiene alcance internacional, debido a los capítulos locales del HL7 que se han creado en distintos países.

Los principales estándares que conforman a HL7 son:

• Mensajería v2.x: mensajería basada en formatos EDI y XML, sin un modelo de referencia detrás.
• Reference Implementation Model: modelo de referencia de HL7, en el que se basan todos los mensajes v3.
• Mensajería v3: mensajería XML basada en el RIM.
• Dominios: la mensajería v3 se divide en dominios específicos de aplicación.
• Clinical Document Architecture: representación de documentos clínicos con XML basados en el RIM.
• EHR System Functional Model: especifica las funcionalidades que debería implementar un sistema de Historia Clínica Electrónica.

Una lista más completa de estándares puede encontrarse aquí: http://upload.wikimedia.org/wikipedia/commons/6/60/HL7_RepEstandares.pdf. Esta es la página oficial de los estándares HL7.

Aquí se puede encontrar una introducción a HL7, con un poco de historia y situación actual: http://es.wikipedia.org/wiki/HL7

La única corrección que se le debe hacer a la página de HL7 en la wikipedia es que HL7 no usa UML para el modelado, si no que extiende de la notación UML (para mi gusto sin necesidad), combinándola con elementos del modelo de esquemas XML (XSD). Más adelante mencionaremos algunos de los problemas de modelado en HL7.

Como organización, HL7 es una organización con base en los EEUU, que se basa en membresías pagas para organizaciones e individuales. A nivel internacional, HL7 tiene filiales en varios países (ver http://es.wikipedia.org/wiki/HL7). La propiedad intelectual de los estándares HL7 es de la organización, y debe pagarse una licencia para utilizar la documentación (no tengo datos de costos, más información: http://www.hl7.com.au/FAQ.htm). HL7 mantiene fuertes vínculos con la ANSI, y varios estándares HL7 son también estándares ANSI. Los estándares HL7 están diseñados con el enfoque de "diseño por comité", donde el foco está en lograr especificaciones con la que todos los miembros del comité estén de acuerdo. Este es un enfoque muchas veces criticado, debido a que el foco no está puesto en lograr especificaciones técnicamente óptimas e implementables, y los miembros del comité tienen diversos perfiles, muchos no técnicos o con poca formación/experiencia en Ingeniería/Arquitectura de Sistemas y en Análisis y Modelado de Información, dos áreas de conocimiento sumamente necesarias para la definición de estándares que luego deberán ser implementados en software. La siguiente imagen resume las críticas al "diseño por comité":

¿Qué no es HL7?

• NO es una aplicación
• NO es una estructura de datos o especificación de base de datos
• NO es una arquitectura para diseñar aplicaciones hospitalarias
• NO es una especificación para un ruteador de mensajes

Nota: esto es algo que se muestra en todas las presentaciones de HL7 en las que he estado, y me parece bueno mostrarlo aquí. Igualmente, a mi criterio, queda claro que cuando uno dice que HL7 es un estándar, si se entiende lo que es un estándar, lo de arriba es redundante.


¿Qué veremos en este artículo?

En este artículo nos concentraremos en los estándares v3: RIM, mensajería v3 y CDA.


HL7 en pocas palabras:

• Define un modelo información de referencia genérico en el cual se basan los demás estándares v3.
• Apunta a resolver la comunicación entre sistemas mediante mensajería XML.
• Objetivo: permitir interoperabilidad entre sistemas heterogéneos.

Modelo de información de referencia genérico:

El modelo de información de referencia de HL7 (HL7 RIM) está basado en cuatro clases de información básicas: Act, Participation, Rol, Entity. Traducido al español esto quiere modelar que en todo Acto, hay Entidades, que Participan jugando algún Rol. Como vemos, es un modelo muy genérico que podría estar expresando cualquier tipo de información en cualquier contexto, incluso fuera de lo que es información clínica. Esta generalidad puede como una ventaja o como una contra. Es una ventaja, porque dentro del complejo mundo de la salud, este modelo puede representar muchísimos escenarios, y es una contra porque esa generalidad le quita valor para representar de forma simple o correcta situaciones muy heterogéneas (como son la mayoría de las cosas en salud). Por otro lado, es un modelo muy simple de entender. En la siguiente imagen se pueden apreciar estas cuatro clases básicas.

Clases centrales del HL7 RIM

Un Acto, según la especificación del estándar, es un registro de algo que se está haciendo, se ha hecho, se puede hacer, o se pretende o se pidió para hacer. Una Entidad es una cosa física, o grupo de cosas físicas, o una organización capaz de participar en Actos jugando algún Rol. La competencia de una Entidad que participa en un acto es identificada, definida, garantida, o confirmada por el Rol que juega en dicho Acto. Una Participación es una relación entre un Rol y un Acto. Como comentamos previamente, estas definiciones pueden aplicarse a cualquier ámbito, por eso este es un modelo de información genérico.

Un punto central en la comprensión del modelo, es que toda la información clínica se debe modelar mediante Actos, ya que las demás clases refieren a información de Entidades (información demográfica) y su Participación según Roles (información administrativa). Las subclases específicas del Acto que modelan información clínica son: Observation, Procedure, DiagnosticImage, SubstanceAdministration, Supply, Diet, PublicHealthCase y podríamos considerar que PatientEncounter también (ya que toda la información clínica debería estar de alguna forma relacionada con el encuentro de un profesional de la salud con un paciente). Por otro lado, también como subclases del Acto podemos encontrar clases para representar información económico/contable como: Account, FinancialContract, FinancialTransaction, e InvoiceElement. Personalmente no estoy de acuerdo con el enfoque de modelar información económico/contable de la misma forma que se modela la información clínica, ya que tienen estructuras y objetivos muy distintos. Aquí se puede encontrar una imagen con el modelo de información de HL7 completo.

El HL7 RIM se basa en un segundo nivel de información básica, donde se definen los tipos de datos (datatypes) que se utilizan en el modelo. El modelo de datatypes está definido por separado al HL7 RIM, y contiene:

• Estructuras básicas: List, Set, Interval, Bag.
• Tipos de códigos: Concept Descriptor, Concept Role, Coded Simple Value, Coded Value, Coded Ordinal, etc.
• Estructuras para representar nombres: Entity Name, Entity Name Part, Trivial Name, Organization Name, Person Name, etc.
• Tipos de magnitudes y magnitudes físicas: Real Number, Ratio, Physical Quantity, Integer Number, Monetary Amount, etc.
• Tipos para tiempos y fechas: Point in Time, Interval of Point in Time, General Timing Specification, etc.
• Otros tipos básicos: History, Telecommunication Address, Universal Resource Locator, etc.

Aquí se puede encontrar una descripción completa de los datatypes HL7.

Una crítica al diseño del modelo de datatypes es que hay elementos que referencian a entidades en el HL7 RIM, por lo que existe un acoplamiento (innecesario) entre el modelo de referencia (primer nivel jerárquico) y el modelo de datatypes (segundo nivel jerárquico). Los ejemplos de esto son los tipos de código donde se referencia al Rol, y en las estructuras para nombres donde se mencionan Entidades, Organizaciones y Personas. Un enfoque más limpio sería que la dependencia de uso fuera en un solo sentido, por ejemplo que el RIM use datatypes, pero que datatypes sea independiente de "quien lo usa". Aquí se puede ver una imagen del modelo de datatypes completo.


Modelo plano

Si vemos al HL7 RIM incluyendo el segundo nivel con datatypes, podemos apreciar que es un modelo bastante plano, esto quiere decir que las estructuras de información necesarias para representar una determinada situación de la realidad no tienen muchos niveles jerárquicos. Por ejemplo, si pensamos en una estructura de árbol, la información representada con HL7 RIM no tendrá más de dos o tres niveles. Si bien esto representa una simplificación a la hora de implementar software (este tipo de estructuras planas son fáciles de implementar, tanto como estructuras en memoria, como estructuras en bases de datos), la información en salud es esencialmente estructurada y jerárquica, o sea que en la realidad tenemos muchos más niveles en nuestro "árbol" de información. En resumen, el modelo es fácil de implementar en software pero se aleja de la estructura real de la información, lo que puede dificultar el modelado de información compleja y altamente jerárquica (más de 5 o 6 niveles).

Por otro lado, si vemos las clases del HL7 RIM, veremos que las clases centrales definen casi todos los atributos que usarán las subclases. Esto va en contra de las mejores prácticas en el diseño orientado a objetos, donde los objetos centrales son los más genéricos y tienen la menor cantidad de atributos, y los objetos más alejados del centro, son los más específicos y tienen más atributos declarados (al tener más atributos son más específicos y representan particularidades de los objetos centrales). El enfoque de diseño de HL7 es todo lo contrario, usando un mecanismo centralizado de atributos (la mayoría declarados en las clases centrales), pero también la mayoría son declarados como opcionales. Mientras que en las subclases se declaran restricciones que indican que un atributo de la super-clase (o clase padre) no será usado. Esto también va en contra de las mejores prácticas en diseño orientado a objetos: un atributo no es declarado en una super-clase si no será usado en una subclase.

El enfoque de modelado plano de HL7 también tiene ventajas. Primero, es simple de implementar en software, tanto en estructuras de datos en memoria, como a nivel de estructuras de base de datos. Creo que quienes lo diseñaron tenían en vista estos elementos, más los elementos de representación de mensajería XML y la especificación de esquemas XML, el XSD, y por eso pasaron por alto las mejores prácticas en el modelado de la información. Esto también trae a la mesa la discusión de si un estándar, y el modelado de información (supuestamente) genérica dentro de éste, debe estar tan ligado a las tecnologías relacionadas con la implementación. Podemos decir que los modelos de información de HL7 son un híbrido entre un modelo de dominio abstracto (independiente de toda tecnología y estructuración de la información como bases de datos, XML o XSD), y la implementación de sistemas concretos. Tal vez estos problemas conceptuales sean parte de que HL7 v3 no sea aún ampliamente implementado. Estos temas quedan planteados para la reflexión y la discusión.

Como resumen, en todo momento no debemos perder el foco de que este modelo de información está orientado a la mensajería, y no está hecho como modelo de información para ser implementado en un sistema de información  De todas formas existe un movimiento para utilizarlo como modelo de información de sistemas de información y bases de datos, como el comité RIMBAA. Mi opinión personal es que es un error conceptual modelar información de la realidad y procesarla y almacenarla según un modelo para mensajería. Tal como dijo el colega Seref Arikan, es como tener tanques de agua y cañerías, pero almacenar el agua en las cañerías (mejor usar los tanques, es decir, los modelos que están hechos para eso). Igualmente les dejo las palabras de Peter Hendler, uno de los integrantes del comité RIMBAA que expresa estas ideas con las cuales discrepo en muchísimos aspectos (ya mencionados):

"The [HL7 version 3] RIM model is too good to be limited to messaging. If someone were to show a programmer the RIM datamodel - and not give them any pre-information that it was created by an organization called HL7, and the scope of HL7 is messaging - if you just put the datamodel in front of a programmer or an architect and say: please look at this model, and you ask them: what do you think this model is for. Probably they'd look at the model and they'd say this is a very comprehensive model which could be used for making healthcare applications and could probably even be used to make persistence layers and relational databases."

Aquí la reflexión de Seref Arikan, con la que concuerdo, al respecto de lo que menciona Peter Hendler:

"I think this is an opinion, not a proven fact, and our field experience is all the contrary: the programmers do not understand the model, and the architects say that this way of modeling breaks all the good practices in modeling information models."

Y ya que estamos en contexto, dejo unas palabras de Tomas Beale (arquitecto y uno de los principales contribuyentes a la especificación de openEHR):

"It is an unavoidable fact (an inconvenient truth) that HL7's approach of putting context/use case specific attributes in general models, and then expecting them to be 'profiled out' is contrary to maintainability and reusability of these models. Where I would like to see them is not my personal choice, it is just a conclusion of basic good modelling practices."


Nota: disculpas por el texto en inglés, pero me pareció mejor dejarlo con las palabras de los autores.


Comunicación mediante mensajería XML:

Una de las cosas que HL7 hace bien (y mucho) es la definición de estructuras para la mensajería. Ya con HL7 v2.x, el cual es uno de los estándares más usados en el mundo (si no el que más) para la mensajería entre sistemas de información en salud. HL7 v3 cuenta con un gran número de mensajes definidos para diversos "dominios", tales como:

• Contabilidad y facturación: Cubre la creación y gestión de las cuentas de pago de los pacientes, con el fin de recolectar los pagos y créditos (transacciones financieras) para apoyar la presentación de reclamos o reembolsos de facturas.
• Prestación de atención médica: Habilita la información necesaria para el cuidado continuo de los individuos, poblaciones y otros sujetos de atención.
• Reclamos y reembolso: Refiere a la facturación (incluyendo la verificación de autorización y elegibilidad), adjudicación y pagos (incluyendo ajustes y consultas de las cuentas) de servicios de salud.
• Apoyo a las decisiones clínicas: Se encarga de definir mensajería para infobuttons. Los infobuttons son instrumentos de información en puntos de atención, que generan consultas online automáticamente sobre recursos de información de salud, utilizando información extraída de la Historia Clínica Electrónica (HCE) del paciente y de información del contexto (datos demográficos, datos de la atención médica actual, etc). Estas consultas sirven para proveer al profesional de la salud de información útil en el cuidado de ese paciente específico.
• Arquitectura de documento clínico: Define una sintaxis basada en XML para definir documentación clínica estructurada. Un documento CDA puede incluir información de distintos tipos: texto, imágenes, sonidos, y otros contenidos multimedia. La estructura de documentos CDA es flexible, pudiendo representar muchos tipos de documentos clínicos diferentes.
• Clínica genómica: Permite la interrelación de información clínica y genómica. Gran parte de la información genómica, aún es genérica, por ejemplo el genoma humano son las secuencias de ADN que se creen comunes a todo ser humano. La visión de medicina personalizada está basada en dichas correlaciones, que hacen uso de información genómica personal, que se diferencia entre dos personas cualesquiera.
• Declaraciones clínicas: Define mensajería útil para la comunicación de declaraciones clínicas. Está definido de forma amplia, por lo que una misma declaración clínica podría tener múltiples formas de representación. Por lo tanto, para ser usado efectivamente, es necesario definir restricciones sobre el modelo de mensajes para cada contexto determinado.
• Tipos de mensajes de elementos comunes: Este dominio se encarga de definir partes de estructuras comunes y reutilizables para los mensajes de diversos dominios.
• Medidas de calidad: Define un estándar para la representación de medidas de calidad en salud, como un documento electrónico. Una medida de calidad es una herramienta cuantitativa que proporciona indicadores de rendimiento de un individuo u organización, en relación con una acción o proceso específico, o como medida de resultados clínicos.
• Inmunización: Refiere a la comunicación de información sobre la inmunización: administración de vacunas y sueros a las personas, para prevenir enfermedades infecciosas.
• Laboratorio: Consta de los mensajes necesarios para la comunicación de información de estudios y observaciones de laboratorio, incluyendo áreas como: química, hematología, serología, histología, citología, anatomía patológica, microbiología y virología.
• Registros médicos: Apoya la gestión y consulta de documentos clínicos.
• Administración de pacientes: Define la información demográfica del paciente, la cual será consumida desde otros sistemas como registros clínicos o sistemas financieros.
• Administración de personal: Contiene la definición de roles, relaciones, credenciales, certificados, capacidades, competencias, cualificaciones, privilegios, responsabilidades y asignación de tareas, emitidos para, o gestionados por, distintas entidades (personas, organizaciones, dispositivos, etc).
• Farmacia: Se encarga de definir mensajería para la prescripción, dispensación, y administración de medicamentos, tanto en farmacias externas como internas a la institución. También define mensajería para la solicitud de información del registro de medicación de un paciente (drogras, recetas, etc).
• Registros: Se encarga de los registros administrativos de personas, pacientes, proveedores, equipamiento y lugares de prestación de servicios sanitarios.
• Reportes de Salud Pública: Incluye los mensajes para apoyar la denuncia e investigación de enfermedades en el contexto de la Salud Pública.
• Productos regulados: Incluye las normas elaboradas para la aprobación de productos regulados, y los mensajes para comunicar información de estos productos.
• Estudios regulados: Incluye normas elaboradas para el intercambio de información sobre la realización de estudios regulados, y la comunicación de la información recolectada durante esos estudios.
• Coordinación: Ofrece un conjunto genérico de mensajes para poder implementar cualquier contexto de coordinación.
• Muestras: Comprende los mensajes relacionados con cualquier tipo de muestra. La información contenido es de la propia muestra, de su envase, y de los contenidos de este antes, durante y después de que la muestra fue colocada en este.
• Dispositivos terapéuticos: Comprende mensajes necesarios para la comunicación relacionada con la terapia y las observaciones hechas por dispositivos médicos. En la actualidad está centrado en los dispositivos cardíacos implantables.

Lo bueno de la división en "dominios", es que ante un desarrollo de software y la necesidad de implementar una determinada comunicación, por ejemplo de la HCE con el laboratorio, podemos encontrar toda la información necesaria en el dominio de laboratorio. A su vez, un dominio puede usar mensajes definidos en otros dominios, en este caso, el dominio proporcionará las referencias a los demás dominios. La desventaja es que cada dominio es creado y mantenido por un comité distinto e independiente de los demás, generando casos de dominios que se solapan. Otro posible problema (depende de cómo se mire), es que al ser tan genéricos, los dominios no son usables de forma directa, si no que es necesario pasar por un proceso previo de restricción y adecuación de los mensajes para usarlos en contextos específicos. Este tema será comentado más adelante bajo el título "guías de implementación".

Para la mensajería, HL7 define un conjunto de elementos:

• Trigger event: es un evento determinado, que debe suceder para lanzar el envío de un mensaje de un sistema a otro. Este evento puede ser lanzado por la acción de una persona sobre el sistema, o del cumplimiento de una determinada condición en el propio sistema (sin intervención humana).
• Message: es el mensaje propiamente dicho, con la información útil. Cada dominio define un conjunto de estructuras de mensajes con propósitos determinados.
• Acknowledge: debido a la naturaleza de algunas transacciones, existen envíos de mensajes que necesitan una confirmación del receptor. HL7 define estructuras de mensajes de confirmación para este tipo de transacciones.
• Control Act: define la estructura intermedia en los mensajes HL7 que da contexto al mensaje, como quien debe recibir el mensaje (lista de distribución) y quién es el autor. Esta estructura es la que contiene la información del mensaje.
• Transmission Infrastructure: define el formato general de los contenedores de mensajes HL7, donde se especifica el emisor, el receptor, el dispositivo que se utiliza para la comunicación (canal), e indica cómo se debe responder al mensaje. Su contenido es el ControlAct.
• Query Infrastructure: define una estructura de mensaje especial, que es utilizada para realizar consultas sobre determinados sistemas usando mensajería HL7. Esto ayuda a que si se tiene un sistema X y se implementa una interfaz de consultas HL7, cualquier sistema que use mensajería HL7 para las consultas, puede obtener datos del sistema X.

Tomando la especificación de mensajes en cualquier dominio, podemos ver que para cada mensaje se define también: quien envía, quien recibe, el ControlAct Wrapper (definido en Control Act), el TransmissionWrapper (definido en Transmission Infrastructure), y el Trigger Event que lanzará el envío de ese mensaje. Aquí podemos ver un ejemplo de definición de un mensaje de laboratorio. Vemos los elementos definidos para el mensaje, cada uno con su identificador. Para hacerlo menos críptico, aquí está el significado de los prefijos de los identificadores:

• MCCI: Message Control Infrastructure
• MCAI: Message Act Infrastructure
• POLB: Laboratory Observations

Más información sobre identificadores aquí.


Guías de implementación: bajando el estándar a tierra

Como mencioné en un artículo previo, la implementación de HL7 no es directa ni trivial, y requiere un esfuerzo de especificación extra sobre la especificación del propio estándar. Esto es debido a que el estándar de mensajería intenta abarcar tantos casos particulares de una sola forma genérica que los mensajes no son usables de forma directa, y debe especificarse cómo se usarán. Esta tarea se realiza mediante "guías de implementación", que son documentos en texto plano, donde se definen las estructuras particulares de mensajes y atributos que se utilizarán en determinado contexto, junto con la semántica de cada campo, vocabularios controlados que serán usados (listados de códigos), etc. Un ejemplo de una guía de implementación para el dominio de Farmacia puede encontrarse aquí.

Siguiendo la especificación de HL7, para el intercambio de mensajes es necesario implementar el modelo de referencia (directa o indirectamente, p.e. implementando solo las clases específicas, no las centrales genéricas), luego es necesario implementar la mensajería genérica (p.e. la estructura de documentos clínicos: CDA), y sobre ésta, implementar los mensajes específicos (en el caso de documentación clínica, serían los documentos específicos como: registro de consulta en ambulatorio, consulta en emergencia, orden de estudios de laboratorio, orden de estudios imagenológicos, prescripción de medicamentos, etc). La siguiente imagen ejemplifica el objetivo de la implementación de mensajes y el proceso real para poder implementarlos.

Implementación de mensajería HL7v3

Interoperabilidad entre sistemas heterogéneos:

Para lograr interoperabilidad, la mensajería HL7 se basa en dos niveles básicos: estructura y códigos.

La estructura está definida por los modelos de mensajería, que a su vez están definidos en función de clases del HL7 RIM. Cada una de estas clases contiene un número de atributos donde aproximadamente la mitad son códigos definidos dentro de algún vocabulario restringido, cada uno con una semántica bien definida. De esta forma, tanto emisor como receptor podrán procesar la información de forma natural, ya que ambos conocen el HL7 RIM, ambos conocen que tipos de mensajes se intercambian (los identificadores de mensajes, trigger events, control acts y message wrappers, están en el propio mensaje), y cada campo codificado tiene asociado un vocabulario restringido, que es básicamente una tabla donde se define para cada atributo, sus posibles códigos, cada uno con su definición en texto narrativo.

El vocabulario controlado de HL7 puede encontrarse aquí.

Este enfoque de estructura + codificación aparentemente alcanza para que el receptor del mensaje pueda "entender" y usar la información contenida en este, dando la idea de interoperabilidad semántica. El problema es que los mensajes son contenedores de información, pero no garantizar en sí que los datos que contienen cumplen con su definición, ni que son consistentes entre sí. Por ejemplo, los documentos clínicos CDA tienen dos niveles de especificación de información: información narrativa (texto libre) e información estructurada (y codificada). El problema es que CDA no define ningún mecanismo que permita controlar que para una misma entrada, la parte narrativa es semánticamente esquivalente a la parte estructurada. En este trabajo se plantean algunos de estos problemas.

Lo que se necesitaría es algún estándar que permitiera verificar la consistencia de la información que viaja en los mensajes HL7, de forma de garantizar que la información y su contexto serán correctamente interpretados del lado del receptor. Con la información sola no alcanza para poder interpretarla correctamente, es necesario tener información de contexto como:

• Quién registró la información: médico, paciente, enfermera, etc.
• Para quién o qué se registró, para quién no: paciente, muestra, etc.
• En qué momento y qué lugar: vía pública, ambulancia, depto. de emergencia, hogar, etc.
• Cómo se registró la información: escritura directa, transcripción, etc.
• Con qué fin fue registrada esa información: histórico, análisis estadístico, investigación.
• Como debería o no debería ser usada esa información.
• Qué consentimientos se tienen sobre la información registrada.
• ¿La información está completa? ¿Es correcta? ¿Qué grado de confianza se tiene?
• Cuantificaciones y evaluaciones: prioridad, importancia, urgencia, gravedad, etc.

HL7 y la IHE

Como comentamos previamente, debido a la generalidad de las estructuras de los mensajes HL7 en cada uno de sus dominios, para poder utilizar estos mensajes es necesario restringir estas estructuras genéricas, adaptándolas a un contexto de uso determinado. Este proceso se llama "profiling" o "perfilamiento". Es un hecho de que los estándares HL7 deben ser perfilados para su uso.

Con este objetivo surge una organización llamada Integrating the Healthcare Enterprise (IHE), que básicamente se encarga de crear y mantener diversos perfiles de los mensajes HL7 para dominios específicos como: Administración de Pacientes, Radiología, Cardiología, Salud Pública, Laboratorio, entre otros. Estos perfiles son especificaciones técnicas que dicen cómo usar estándares genéricos en contextos específicos, por lo tanto podríamos decir que un perfil es como un caso de uso.

Por este motivo, cuando queramos implementar mensajería HL7 para algún contexto específico, es bueno primero visitar las especificaciones de IHE donde se puede encontrar algún perfil que satisfaga los requerimientos.

IHE básicamente trabaja con estándares de ISO, HL7, DICOM y W3C. Igualmente, los conceptos detrás de los perfiles pueden aplicarse a diversos estándares. Por ejemplo, uno podría implementar el perfil de Laboratorio usando mensajería CEN 13606 basada en arquetipos, en lugar de usar mensajería HL7.

El hecho de que se necesite una organización para definir cómo se usan los estándares creados por otra organización, parece absurdo. Creo que esta es una de las cosas que le juegan en contra a la adopción de HL7 v3, porque me parece que HL7 es lo suficientemente fuerte (como organización) para definir perfiles a sus propios estándares. Por otro lado, también juega en contra de que se quieran crear mensajes universales, tal que un único mensaje pueda modelar cientos de contextos distintos. Esto hace inusable al estándar en sí, y apoya al surgimiento de organizaciones como IHE.

Conclusiones

En este artículo introductorio intenté dar una mirada crítica e independiente a los estándares HL7, la cual entiendo que es necesaria porque creo que hay una falta de este tipo de miradas. También noto que cuando se habla de HL7, a veces sin haberlo investigado o probado, se tiene la idea de que es el único estándar y que soluciona todos los problemas de interoperabilidad, en cualquier ámbito, y con una inversión mínima de tiempo. Si bien HL7 tien muchas fortalezas, estas ideas están alejadas de la realidad. De lo contrario, ya tendríamos un sistema integrado de salud basada en HL7v3 funcionando hace años.

HL7 como organización es consciente de muchos de los problemas actuales, y está haciendo esfuerzos para mejorar los estándares. Por ejemplo, en este momento se está trabajando en la próxima versión de documentación clínica CDA (CDA R3), la cual estoy seguro de que traerá soluciones a muchos de los problemas que hoy tiene CDA R2.

Ventajas:

• Permite crear un marco de comunicación a gran escala.
• Es un excelente punto de partida para discutir cómo vamos a comunicar (no así para saber qué vamos a comunicar).
• No hay otro estándar de mensajería tan ampliamente difundido (e implementado en el caso de HL7v2).
• El más completo (en referencia a los dominios)
• Capacidad de integrar terminologías estándar (CIE, SNOMED, etc).
• Esquema de comunicación simple, basado en eventos y mensajes.
• HL7 v3 se basa en mensajería XML.

Desventajas:

• Complejidad: un solo modelo, más de 20 dominios, decenas de CMETS, mensajes e interacciones.
• No es aplicable directamente, necesita acuerdos previos y la construcción de "guías de implementación", por lo que cuarta las posibilidades de una interoperabilidad semántica global.
• No garantiza interoperabilidad semántica básica o global: para la primera necesita guías de implementación y para la segunda no provee mecanismos como si proveen ontologías y arquetipos.
• Especificaciones crípticas (hay que hacer un curso para entenderlas, literalmente), solo en inglés, ambigüas y dependientes de la interpretación. La especificación completa de HL7 ocupa 2 CDs sin comprimir.
• No usa estándares de modelado (UML), presenta problemas en el modelado de la información (clasificación, ambigüedad).
• Calidad variable, complejidad de evaluación y trabajo en comités.
• Requiere de una organización externa, con especificaciones propias, para implementarse correctamente. (IHE)
• Necesita perfilamiento para poder aplicarlo, lo cual es un gran costo en tiempo