5 de diciembre de 2009

Super estandares en informatica medica


De distintas charlas profesionales tanto informáticos cómo médicos acerca de los estándares en informática médica, sobre todo en HL7, he notado que varios conceptos no están del todo claros o literalmente no saben de lo que están hablando. Por ejemplo muchos piensan que HL7 es un solo estándar y que su aplicación es directa, cómo definir el estándar para una entrada de corriente: tanto el macho cómo la hembra son especificados de forma estándar y cuando son fabricados por distintos proveedores, si cumplen con el estándar, macho y hembra encajan a la perfección. En la informática médica este es un ideal que no podrá ser logrado mientras estos conceptos no estén claros. Y se podría afirmar que sería imposible que HL7 u otros estándares funcionen de esta manera.

Primero cabe aclarar que HL7 es una organización que crea estándares, y que si vemos a HL7 como estándar, es en realidad un gran conjunto de estándares dedicados sobre todo a resolver la comunicación entre sistemas clínicos y administrativos. Estos estándares aplican a áreas específicas o “dominios” dentro del ambiente de la salud.

Si por “estándar” pensamos en el ejemplo de la entrada de corriente la cual se conecta y encaja perfectamente, en realidad HL7 se comporta como un “súper estándar” porque no tiene esa capacidad, o sea que es un paso previo o superior a la aplicación de un estándar. En el mundo de HL7 para que cualquier estándar sea implementado es necesario definir las llamadas “guías de implementación”, las cuales especifican acuerdos entre distintos actores para definir cómo implementarán uno o varios estándares HL7, o sea que sin un acuerdo previo es prácticamente imposible que dos o más sistemas intercambien mensajes HL7 y lleguen a interoperar semánticamente.

Existe una organización llamada Integrating the Healthcare Enterprise o simplemente IHE que se encarga de definir especificaciones de cómo utilizar mensajería HL7 para cumplir con determinados propósitos, por ejemplo resolver toda la mensajería necesaria para tener informatizados los ciclos de pedido, reporte y consulta de exámenes imagenológicos. Estas especificaciones se llaman “perfiles” y cada perfil aplica a un dominio particular como ser: anatomía patológica, cardiología, oftalmología, laboratorio, coordinación de cuidado del paciente, oncología, radiología, etc. Si bien IHE no es un estándar, si no que es una forma de usar los estándares HL7 y DICOM (para radiología digital), es una orientación a las guías de implementación HL7 para definir acuerdos entre los actores, así que podría verse como un estándar complementario o de guía.

En definitiva logramos una relación cómo la descrita en la figura 1.


Figura 1.


HL7 no es el único “súper estándar”, existen otros como OpenEHR o DICOM, dos con una característica común: son estándares abiertos.

OpenEHR intenta resolver la forma en que se desarrollan los sistemas de información clínicos, que son los sistemas que forman la ya conocida Historia Clínica Electrónica. OpenEHR plantea una arquitectura con los distintos componentes del sistema, propone un completo modelo de información clínica y administrativa, y propone la “orientación al conocimiento” de los sistemas de información en salud, a través de sus Arquetipos. Los arquetipos son la forma de expresar conceptos médicos en un formato computable, y es la forma de bajar del “súper estándar” al estándar aplicable. Los arquetipos también son la forma de especificar los acuerdos entre los actores, es decir que si dos o más actores implementan su propia Historia Clínica Electrónica y se ponen de acuerdo en los arquetipos de los conceptos clínicos que manejarán en cada historia, luego podrán intercambiar información clínica sin problemas. Los conceptos pueden ser por ejemplo: “presión arterial”, “administración de medicamento”, “escala de coma de Glasgow”, etc.



Figura 2.


En el mundo de los exámenes imagenológicos digitales encontramos al estándar DICOM, otro súper estándar. DICOM propone un modelo de información y un conjunto de interacciones o transacciones entre sistemas los cuales se ejecutan para automatizar los procesos de: solicitud de un estudio, coordinación de un estudio, ejecución del estudio, elaboración del informe por el radiólogo, entrega del informe al médico solicitante. Cómo DICOM es un “súper estándar” es necesario llegar a un acuerdo previo para definir cómo será utilizado, en el mundo DICOM este acuerdo se llama “DICOM Conformance Statement” ó “Declaración de Conformidad DICOM”. Éste es un documento que especifica todas las decisiones particulares que un proveedor tomó al implementar la norma, el cual debe entregar cada vez que quiera conectar su producto con otros productos “DICOM compatibles”, o sea que esta declaración de conformidad en realidad no es un acuerdo entre actores, si no que es una forma de mostrarle a otros actores cómo es que un sistema implementa DICOM. El capítulo 2 de la norma DICOM define qué es la declaración de conformidad y cómo debe ser creada.


Figura 3.


En conclusión, los estándares propuestos en el área de la salud no son por sí mismos estándares aplicables, si no que son “súper estándares”, los cuales necesitan de acuerdos y decisiones previas que bajen la complejidad y generalidad de los mismos a algo implementable en un sistema de información clínica. Por lo tanto debemos tener cuidado al comprar productos que se ofrezcan como “compatibles HL7” o “compatibles OpenEHR” o “compatibles DICOM”, lo que necesitamos realmente son: las guías de implementación, los arquetipos o la declaración de conformidad, respectivamente.