22 de diciembre de 2011

Vota por mi blog en e concurso de Healthline

Vota por mi blog "INFORMÁTICA MÉDICA Y ESTÁNDARES" para el concurso de blogs de healthline http://www.healthline.com/health/best-health-blogs-contest


www.healthline.com
Enter Healthline's Best Health Blog of 2011 Contest & be eligible to win up to $5000. Nominate & vote for your favorite health, fitness & wellness blogs now!




Se agradece la difusión!

14 de diciembre de 2011

Iniciativa de modelos de informacion clinica: openEHR elegido

CIMI (Clinical Information Modeling Initiative) es una colaboración internacional que busca proporcionar un formato común para las especificaciones detalladas de la representación de la información de salud, buscando que la información semánticamente interoperable pueda ser creada y compartida entre diversos registros de salud, mensajes y documentos.

Les dejo el texto original de la selección de los modelos, perdonen que está en inglés (usar google translate para leer en español: http://translate.google.com/).


Clinical Information Modelling Initiative goes with Archetypes & UML profile

[press release from the CIMI group]

The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents. CIMI has been holding meetings in various locations around the world since July, 2011. All funding and resources for these meetings have been provided by the participants. At its most recent meeting in London, 29 November - 1 December 2011, the group agreed on the following principles and approach. 

Principles

1. CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers.

2. CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.

3. CIMI is committed to transparency in its work product and process.

Approach
  • ADL 1.5 will be the initial formalism for representing clinical models in the repository.
    • CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
    • Modifications will be required and will be delivered by CIMI members on a frequent basis.
  • A set of UML stereotypes, XMI specifications and transformations will be concurrently developed using UML 2.0 and OCL as the constraint language.
  • A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012.
    •  Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process.
  • A plan for establishing a repository to maintain these models will continue to be developed by the group at its meeting in January.
Representatives from the following organizations participated in the construction of this statement of principles and plan

Further Information
In the future CIMI will provide information publicly on the Internet. For immediate further information, contact Stan Huff (stan.huff@imail.org)

18 de noviembre de 2011

Curso de openEHR en español: inscripciones abiertas

1er curso virtual de openEHR en español



“openEHR: EL ESTÁNDAR ABIERTO PARA HISTORIAS CLÍNICAS ELECTRÓNICAS A PRUEBA DE FUTURO”



Luego de grandes esfuerzos y la ayuda invaluable de los amigos de ACHISA, pudimos lanzar el curso antes de fin de año.

En la página de ACHISA están los datos del curso, el temario y el formulario para inscribirse. Por favor no esperen hasta el último momento para inscribirse porque tenemos poco tiempo!

Info: http://www.achisa.org/

Inscripción: https://docs.google.com/spreadsheet/viewform?formkey=dFhfNTdiUkNFU0pXaldfcGczN1JELVE6MQ

Temario y cronograma: http://www.achisa.org/PDF/Brochure_OpenEHR_ACHISA_ed1.pdf


Los esperamos!

16 de octubre de 2011

Curso de openEHR en español

Estimados,

He definido el temario del curso. Ahora estoy intercambiando con colegas para evaluar su interés en la temática del curso y poder definir una fecha de comienzo.

Lo estoy preparando para que sea virtual, tal vez en una segunda edición podría hacerse de forma presencial.

Los requisitos para el curso son bastante laxos porque la idea es hacerlo amplio y autocontenido, pero es bueno si el alumno/a tiene nociones en:
  • UML: modelado de entidades y procesos
  • Arquitectura de sistemas
  • Sistemas de información (mejor si son en salud)

El tiempo total del curso para el alumno está calculado en 50hs: 24hs de clase, 16hs en 2 trabajos obligatorios, y 10 horas de estudio/lectura personal.

En este momento me encuentro terminando de armar y traducir el material de lectura que usaremos como referencia en el curso.

Aquí les dejo el temario actualizado al 29/10/2011:

Semana 1
  • Clase 1
    • Principales problemas de los sistemas informáticos clínicos.
    • Soluciones desde openEHR para resolver estos problemas.
    • Portal de openEHR internacional: recorrida para buscar información útil.
    • Los proyectos openEHR: especificación, software, modelos clínicos.
    • Conceptos clave en openEHR: el modelo dual, arquetipos, plantillas, conceptos clínicos, estructura de la información clínica.
  • Clase 2
    • El EHR según openEHR
    • Plataforma informática de EHR
    • Principales requerimientos de un EHR (ISO 18308 y openEHR).
    • Introducción al modelo dual y al modelo multinivel.
    
Semana 2
  • Clase 3
    • Introducción al modelo de información de openEHR: modelo de entradas basado en el modelo de resolución de problemas clínicos y la ontología de registro clínico.
    • Principales clases del modelo de información de openEHR: Composition, Section, Entry, DataStructure, History, Cluster y Element. Relación con otros modelos (HL7v3, ISO 13606, ASTM CCR).
    • Modelo de tipos de datos de openEHR. Relación con otros modelos (HL7v3, ISO 13606, ASTM CCR).
  • Clase 4
    • Modelo demográfico. Relación con otros modelos (HL7v3, ISO 13606, ASTM CCR).
    • Ejemplo de instancia completa de los modelos: EHR, tipos de datos y demográfico.
    
Semana 3
  • Clase 5
    • El modelo dual: conceptos, objetivos, artefactos.
    • Modelo de conocimiento: conceptos clínicos
    • Introducción a ADL (Archetype Definition Language)
  • Clase 6
    • Introducción a AOM: el modelo de arquetipos. Conceptos básicos: identificadores, rutas, versiones, ocurrencias, cardinalidad.
    • Ejemplos de ADL y AOM.
    • Conceptos de desarrollo de arquetipos y control de control de versiones.
    
Semana 4
  • Clase 7
    • Archetype Editor: creando nuestros primeros arquetipos.
    • Clinical Konwledge Manager: utilizando arquetipos existentes.
    • Trabajo 1: Presentación del taller de modelado.
  • Clase 8
    • Creando arquetipos avanzados: instrucciones y acciones. El manejo de la máquina de estados de la instrucción.
    • Caso de estudio: modelado y funcionamiento de instrucciones y acciones.
    
Semana 5
  • Clase 9
    • Introducción a plantillas y cambios para AOM 1.5. Restricciones de validez.
    • ADL Workbench: validando arquetipos.
    • Open EHR-Gen Framework: caso práctico de uso de arquetipos en un EHR.
  • Clase 10
    • Estrategias de implementación de openEHR, uso de arquetipos y plantillas en la práctica.
    • ¿Cómo integrarlos a nuestros sistemas de información?
    • Visión desde los datos, estrategias de persistencia de información clínica jerárquica.
    • Visión desde la interfaz de usuario.

Semana 6
  • Clase 11
    • Integración de openEHR con otros estándares: DICOM, CDA, HL7v3, Terminologías y codificaciones.
    • Trabajo 2: planteo de temas para el trabajo escrito.
    • Entrega del trabajo 1.
  • Clase 12
    • Conceptos de seguridad, control de acceso, confidencialidad e integridad de los datos en openEHR.
    • Conceptos de control de cambios, eventos, contribución, participación, firma, auditoría.
    • Resumen y conclusiones del curso.


Y este es un texto a modo de motivación para difundir el curso:

1er curso virtual de openEHR en español



“openEHR: el estándar abierto para historias clínicas electrónicas a prueba de futuro”



El estándar openEHR define las bases para crear sistemas de historia clínica electrónica normalizados, flexibles, adaptables, extendibles, genéricos e interoperables.


Su propuesta de “modelo dual” basado en artefactos de conocimiento presenta un cambio de paradigma en el desarrollo de los sistemas de información en salud. Esta propuesta habilita a la evolución del conocimiento y la información clínica de forma independiente a los cambios tecnológicos. Permitiendo así la evolución de los sistemas de información en salud.



Los artefactos (arquetipos, plantillas y terminologías) pueden ser creados y compartidos entre distintos sistemas, manteniendo una coherencia semántica y consistencia estructural que permite la interoperabilidad semántica entre sistemas.





Estos artefactos forman una “base de conocimiento” que permite crear una historia clínica virtual, formada por diversos sistemas de información clínicos y paraclínicos, creados con diferentes tecnologías y objetivos, para brindar un conjunto global de servicios de forma homogénea.
Este enfoque busca crear un contexto distribuido, abierto e independiente para los sistemas de información en salud, y es diametralmente opuesto al enfoque centralizado-monolítico.
Aunque ambos enfoques buscan lograr el mismo resultado, el centralizado-monolítico no se corresponde con la realidad distribuida de los sistemas de salud, y parte del fracaso de la informatización en salud se debe a este hecho.

El nuevo paradigma de openEHR propone una mejor solución que vale la pena explorar. http://en.wikipedia.org/wiki/OpenEHR


30 de septiembre de 2011

Capacitacion en openEHR: estándar libre de HCE

Disculpen la introducción tan personal, quiero dar el contexto completo del tema principal de este artículo: diseñar cursos sobre openEHR.

Un poco de contexto: haciendo un balance personal

Desde 2006 formo parte de la comunidad de openEHR internacional. Primero estudiando el estándar, luego probando distintas partes de la implementación. En 2010 terminé mi tesis de grado con un proyecto 100% basado en openEHR: el estándar libre para el desarrollo de historias clínicas electrónicas. Y en 2011 escribí junto a la Dra. Selene Indarte una publicación para CEPAL sobre interoperabilidad y estándares en Informática Médica (IM) (espero se publique antes de fin de año, igual pronto haré un artículo con los principales puntos de la publicación).

Hoy ya soy Ingeniero en Computación (título en trámite), sigo especializándome en estándares en IM (openEHR sobre todo), dirijo un proyecto de código abierto basado en openEHR, y he dictado capacitación y he dado charlas sobre distintos estándares (openEHR, HL7 CDA, CCR/CCD, DICOM, ...).

El perfil que estoy tratando de construir no está basado en el desarrollo de aplicaciones (en realidad programo por necesidad), lo que más me gusta es la gestión de proyectos, diseño y arquitectura de sistemas, la docencia, y la asesoría de proyectos en temas de estándares en IM e interoperabilidad.

Desde hace un tiempo, todo lo que leo y todo lo que aprendo trato de compartirlo con la comunidad, porque estoy convencido de que el conocimiento que no se comparte, no tiene razón de ser. Este blog es prueba de eso. También otros blogs y grupos de discusión que he creado. Hoy estoy tratando de formalizar un poco esa tarea de compartir conocimiento, y me encuentro armando un curso dirigido a openEHR, aunque rozando otros estándares importantes.


¿Porqué un curso de openEHR?

Hoy en día, openEHR es el único estándar orientado a la creación de sistemas de Historia Clínica Electrónica (HCE), de forma que sea interoperable desde el registro de la información clínica. Mi visión personal es que openEHR plantea una guía de cómo construir una buena HCE, mientras que otros estándares se centran en comunicar información clínica sin importar mucho si la HCE es buena o mala, es decir, si al comunicar la información que esta contiene, el resultado será consistente con el propósito de la información cuando esta fue registrada.

En mi artículo de introducción a openEHR puedes encontrar más información.

Además, consideremos el contexto actual en América Latina y el Caribe: existen numerosos proyectos de HCE en curso, se está comenzando a masificar el dictado de capacitación formal en IM tanto a informáticos como a médicos, y hay múltiples eventos cada mes que tocan el tema de la HCE. En este contexto ¿importa más crear una buena HCE o la comunicación entre sistemas? Mi respuesta es la primera, ya que la comunicación no puede existir si una buena HCE.

Otro argumento fuerte es que múltiples instituciones se encuentran en proyectos de reingeniería, cambiando sus HCEs anteriores por nuevas. Y esto no es un recambio tecnológico, es una adecuación de la HCE a la realidad, es decir que las HCEs anteriores no eran del todo buenas. ¿Qué hubiera pasado con buenas HCEs? Una buena HCE es flexible y adaptable por diseño, y si consideramos los costos de reingeniería, tal vez nos salga más barato invertir más tiempo en crear buenas HCEs.


El curso de openEHR que estoy diseñando

La idea central del curso es brindar una visión global del estándar, que se concentra en partes clave como el modelo de información y el modelo de arquetipos. Pero como no me gusta quedarme en lo conceptual, voy a mostrar cómo se integran esos conceptos con sistemas informáticos reales.

El núcleo del curso está basado en un taller que dicté el año pasado en el Congreso Argentino de Informática y Salud: http://www.slideshare.net/pablitox/taller-open-ehr-cais-2010-pablopazos
Este taller fue un verdadero desafío. Fueron 4 horas de taller y vinieron unas 14 personas (era más de lo que esperaba porque nadie me conocía y al lado había una charla de HL7 con gente super conocida). Igual la gente vino (y se quedó!), el 80% eran médicos, y la verdad se engancharon mucho con la temática. Luego me dio un poco de lástima que no pudieran profundizar más en el tema, y desde entonces me quedé con "la espina" de hacer algo más. Interés hay.

Este es un ejemplo de temario simplificado del curso:
  • Conceptos básicos: ¿qué es openEHR? ¿qué es un arquetipo? ¿qué es un template?
  • Analizando la realidad: conceptos clínicos, registros, procesos, estandarización, especificación.
  • Modelado: conceptos clínicos, información, interfaz de usuario, reglas de negocio.
  • Herramientas disponibles: gestor de conocimiento, editor de arquetipos, implementaciones de referencia.
  • Casos de estudio: creando una HCE para distintos dominios (emergencia, ambulatorio, internación, distintas especialidades)
  • Integración con estándares de contenido: Snomed, CIE 9, CIE 10, CIAP-2, Mesh, ATC.
  • Relación con otros estándares: ISO 13606, HL7 CDA, DICOM.
  • Comunicación con sistemas externos: interoperabilidad sintáctica, semántica y de negocio/proceso.

También estoy jugando con la idea de hacer algo especialmente para médicos con orientación informática, orientado a el modelado de información clínica, que podría ser un subconjunto del temario anterior. El objetivo de este cursillo sería promover métodos, herramientas, buenas prácticas y modelos de información clínica, para que los médicos que se encarguen de diseñar los registros clínicos, tanto electrónicos como en papel, puedan hacerlo lo mejor posible.

Algunos puntos que se podrían incluir son:
  • Conceptos básicos: ¿qué es un ...? (modelo, dato/información/conocimiento, proceso, registro, historia clínica, estructura de información, protocolo, estándar, concepto, ...).
  • Análisis de un caso de estudio: diseñar el registro clínico para el mismo.
  • Entre la libertad de registro y el registro estructurado: ventajas y desventajas.
  • Estructurando el registro: desde el dato a la historia clínica
  • Modelos de información clínica: identificando conceptos de la HC con openEHR, HL7 CDA, ASTM CCR e ISO 13606.
  • El registro contextualizado al proceso de atención: ¿quién? ¿para quién? ¿cuándo? ¿cómo? ¿dónde?
  • Análisis de caso de estudio: revisitando el caso de estudio y volviendo a diseñar el registro clínico.
  • Puesta a punto evaluando las diferencias entre los dos casos de estudio.


Planificación para el futuro

Uno de los objetivos de este artículo es medir el nivel de interés en la temática que planteo. El otro es saber su opinión sobre la temática, sobre lo que podría ser más interesante para incluir, o sobre lo que se podría hacer más hincapié.

También me gustaría ponerme en contacto con instituciones afines con la temática donde pueda dictar el curso, ya que mi idea para los próximos meses es vivir de la docencia. Además que voy a comenzar con mis estudios de maestría y podría hacer algún curso en la misma institución (para matar dos pájaros de un tiro).


Espero sus comentarios, y si saben de alguna institución que se pueda interesar, me avisan. Se agradece la difusión!


Un abrazo a todos.


PD: en mi cuenta de SlideShare hay más recursos.

23 de septiembre de 2011

Nueva version de OpenEHR-Gen Framework

Estoy muy contento de anunciar una nueva liberacion de Open EHR-Gen Framework, la herramienta libre para crear sistemas de Historia Clínica Electrónica basados en estándares internacionales como openEHR, HL7 CDA y CIE 10.

La nueva versión 0.6 está disponible para la descarga aquí: http://code.google.com/p/open-ehr-gen-framework/downloads/list

 OpenEHR-Gen Framework es 100% código abierto y gratuito. Se agradece la difusión del mismo. 

¿Qué quiere decir esto? Que cualquiera puede bajar el código, probarlo, modificarlo, hacerle mejoras y adaptaciones a la realidad de cada institución sanitaria, y podrá contribuir con el desarrollo en comunidad de la herramienta.

¿Qué valor ofrece este proyecto? ¿Qué lo hace distinto?

En el corazón de la herramienta están considerados aspectos de estandarización que aportan a la interoperabilidad del sistema con cualquier otro sistema externo (farmacia, laboratorio, imagenología, sistemas administrativos, etc).
Otro diferenciador es la orientación a la gestión del conocimiento clínico, a través del uso de arquetipos openEHR como especificación del contenido del registro clínico. Ver más sobre arquetipos en el gestor de conocimiento clínico: http://www.openehr.org/knowledge. ¿Esto en qué te beneficia? En el el proceso de desarrollo de software es independiente del proceso de especificación del contenido clínico, y el resultado es un mejor proceso global, una herramienta de software más ligera y adaptable, y el control completo del contenido clínico por parte de los médicos.
Por último, está desarrollado sobre tecnologías web de nivel empresarial de última generación, como ser Grails, Groovy y Java.

Principales cambios con respecto a la versión anterior (*):
  • Reescritura completa del generador de interfaces de usuario, con gran aumento de performance.
  • Se agrega un gestor de usuarios y de roles.
  • Se modifica el modelo de datos persistentes para simplificarlo y mejorar performance de lectura-escritura de la base de datos.
  • Se sustituye librería javascript Prototype por jQuery. Con jQuery se implementa parte de la nueva generación de interfaces de usuario.
  • Se hacer varias correcciones y mejoras al componente data binder.
  • Se cambia un poco el estilo de la interfaz de usuario.
(*) Aquí se puede ver más información sobre la versión anterior, y puedes encontrar presentaciones y documentos sobre el proyecto.


Algunas capturas de pantalla de la nueva versión (clic para ver en grande):

Ingreso al sistema

 Selección de dominio
Ingreso a dominio de trauma

Registro en dominio de trauma

Registro de triage en trauma

Registro de triage almacenado

Evaluación primaria de trauma: vía aérea

Evaluación primaria de trauma

 Evaluación primaria de trauma

 Evaluación primaria de trauma

 Evaluación primaria de trauma: disfunción neurológica

 Búsqueda de paciente para asociar al registro clínico

Resultado de la búqueda

Registro clínico con paciente seleccionado


 Gestión de personas

 Detalle de una persona


Listado de roles

Detalle de un rol

 Edición de permisos de un rol

 Rol con permisos guardados


Como siempre, todas las preguntas y comentarios son muy bienvenidos.

13 de septiembre de 2011

openEHR busca lograr impacto global

Hace algunos meses que las listas de mail de openEHR están colmadas de propuestas sobre cómo mejorar la organización de la fundación openEHR, cómo coordinar el trabajo y cómo lograr resultados tangibles.

En estos días, muchas de estas propuestas fueron consideradas por las principales cabezas detrás de openEHR, y se están viendo avances. El avance más grande es un whitepaper que, a modo de manifesto, intenta reflejar el camino que tomará la fundación en el futuro cercano, tanto en temas organizativos como en el desarrollo del estándar y de herramientas relacionadas.

Éste es el link al whitepaper (que sigue en edición): http://www.openehr.org:8888/openehr/321-OE/version/default/part/AttachmentData/data/openEHR%20Foundation%20moving%20forward.pdf

También quiero dejarles los links a las principales discusiones sobre los temas del whitepaper:

- Anuncio de cambios: http://www.openehr.org/mailarchives/openehr-clinical/msg02145.html
- Sobre repositorios de conceptos clínicos (arquetipos y plantillas): http://www.openehr.org/mailarchives/openehr-clinical/msg02149.html  y  http://www.openehr.org/mailarchives/openehr-clinical/msg02146.html


Otros temas como la alineación a estándares como EN/ISO 13606 y HL7 CDA también están en la mesa.

Para quienes quieran participar de las discusiones, aquí están las listas para suscribirse: http://www.openehr.org/community/mailinglists.html

Por mi parte, creo que la descentralización es uno de los temas más importantes para lograr un impacto global en el uso de este estándar que promete mucho, pero que tal vez por falta de difusión y capacitación, es poco conocido en nuestra región. Creo que una vez que openEHR ingrese formalmente en la currícula de la formación en Informática Médica, la realidad será otra y podremos aprovechar lo que el estándar ofrece: permitir crear sistemas informáticos en salud "a prueba del futuro".

30 de agosto de 2011

Gestion de proyectos de informatizacion en salud

La informatización en el área clínica es un camino que muchas instituciones sanitarias están emprendiendo a nivel mundial. Este camino no es sencillo, está lleno de obstáculos, problemas, desentendimientos, expectativas incumplidas y proyectos fallidos.

Es este contexto tan hostil, ¿existirá alguna metodología o proceso que nos acerque al éxito o nos aleje del fracaso?. El objetivo de este artículo es dar mi opinión personal sobre algunas "áreas sensibles" que los gestores de proyectos deberían cuidar para que "el bote no haga agua".

Algunos de estos puntos podrán coincidir más o menos con los métodos y estrategias usados por los gestores de proyectos, y deberían considerarse como la humilde opinión de alguien que observa y analiza la realidad (de cerca), no como una solución a todos los problemas. Además trato de hacer énfasis en el "qué", no en el "cómo", pero la discusión está abierta.


El proyecto debería ser solo un grano de arena

El proyecto de informatización debe ubicarse en una estrategia organizacional de mejora, el proyecto no debería ser la estrategia, sino un resultado de esta.
Tener claro este punto facilita que el apoyo de los tomadores de decisión de la institución se haga visible, y ubica al proyecto en un lugar de la agenda institucional. De lo contrario, el apoyo se hace esquivo, y no se tiene una puerta donde ir a tocar cuando hay problemas a nivel de la institución.


La informatización es un camino solo de ida

Junto a la planificación de las distintas etapas de desarrollo e implantación de las soluciones informáticas en el área clínica, debería planificarse la estrategia de eliminación del papel de los procesos clínicos.
Dejar "vivo" al papel es atentar contra el uso de los productos del proyecto.


Evitar el proyecto de duración infinita

Todo gestor de proyectos sabe que un elemento característico de éstos es que tienen una fecha de fin.
Esa fecha de fin debería ser fija e inamovible, y se debería tener claro qué es lo que se va a entregar y qué es lo que no. Tres factores se debe tener en cuenta siempre: el alcance (cantidad y complejidad de necesidades a satisfacer), la calidad (cantidad de ciclos de mejora sobre una necesidad satisfecha) y el tiempo (demora en satisfacer una necesidad o de mejorar la forma en la que esta es satisfecha). Se dice que tenemos 3 balas y solo podemos disparar 2, por ejemplo un proyecto con un alcance muy grande y con gran calidad, requerirá mucho tiempo en desarrollarse. Otra posible combinación es que si tenemos poco tiempo y un alcance fijo, no podemos pedir mucha calidad. La regla general es que si aumentamos alcance, calidad o tiempo, aumenta el costo/presupuesto.
Siempre hay aspectos que pueden mejorar, y siempre habrá tiempo para mejorarlos, pero sobre la entrega de los productos no podemos empezar procesos de mejora. Es mucho mejor para el proyecto, para el proveedor y para el cliente: 1. entregar lo pactado, ni más ni menos; 2. aceptar lo que se debe entregar; 3. cerrar el proyecto; 4. sentarse a pensar en mejoras (...y ver si queda algo de presupuesto).


Las expectativas y la comunicación son también elementos a gestionar

Luego de fijar el alcance del proyecto, los clientes y los usuarios finales deberían saber qué es lo que se va a entregar y cuándo. Esto incluye el saber que es lo que NO se va a entregar.
La comunicación de estos elementos se debería hacer en cada oportunidad que se tenga, y si no se dan estas oportunidades, se deben crear. Por otro lado, todos los usuarios finales (sobre todo los médicos) tienen una idea de lo que quieren, y todos se imaginan que el producto será exactamente como ellos lo imaginan. Para evitar desilusionar a estos usuarios (riesgo a rechazo del producto), se debe dar una imagen clara del producto, de lo que tendrá y no tendrá, y bajar o subir las expectativas al nivel correcto. Esto también debería hacerse en todas las oportunidades que se tengan.


Contraparte es algo más que once letras

Sin contraparte no existe proyecto. Si somo un proveedor de software, la contraparte está formada por los tomadores de decisión, los usuarios finales y el staff informático del cliente. El cliente debe ser comunicado claramente de que para que el proyecto sea un éxito, se necesita tiempo de trabajo de los recursos humanos de la institución: médicos, enfermeras, técnicos, informáticos, etc.
Una forma de que el cliente tome conciencia de esta necesidad es que sepan claramente cómo será el proceso de desarrollo e implantación de los productos del proyecto, y que en cada una de esas etapas se requerirá la participación de ciertos roles claves, que necesitan un tiempo asignado a esas tareas, y que deberán dejar de hacer otras tareas que hoy tienen asignadas.
Este punto es tan obvio que muchas veces los gestores lo pasan por alto, y como consecuencia se pierde tiempo por no contar con alguien del otro lado a quien hacerle preguntas o con quien discutir posibles soluciones a los problemas que el propio cliente plantea.


Mantener las audiencias y el interés es un gran punto a favor

En los proyectos de informatización en salud se tienen dos grandes audiencias: los tomadores de decisión y los usuarios finales. Es frecuente que por la poca visibilidad del proyecto y sus avances, por la poca comunicación, o a veces por la duración tan prolongada de estos proyectos, las audiencias que antes nos apoyaban, aportaban y se interesaban por el proyecto, ya no están tan interesados.
Perder el interés de las audiencias, es perder apoyo y ganar resistencia, lo que es un gran punto en contra para el proyecto. El interés es otro punto a gestionar y cuidar, porque hay que recuperarlo antes de que sea demasiado tarde, por ejemplo: que se entregue el producto y nadie lo use.
A los gestores les gusta saber que se tienen productos listos, y a los usuarios les gusta dar su opinión y ver como esta repercute en el producto que van a usar. Ellos debe participar en todas las etapas del proyecto!.


El proyecto informático médico

La informática es un camino para lograr un objetivo, no debería ser considerado como el objetivo en si.
Tanto los tomadores de decisiones como los usuarios finales no deberían hablar de bases de datos ni servidores, con ellos y a ellos siempre se les debería hablar en un plano médico de usos y funcionalidades que soportará la herramienta. Como estrategia general, el proyecto debería presentarse como un proyecto médico, no un proyecto informático.


El paradigma del hiper-mercado vs. las pequeñas tiendas especializadas

Existen dos formas de encarar los proyectos de informatización en salud. El primero y más frecuente, es el de una gran herramienta centralizada, con una única base de datos, que provee soporte a diferentes sectores y diferentes usuarios. Donde los requisitos y necesidades de cada uno de estos sectores y usuarios es esencialmente distinto al de los demás. Este tipo de proyectos suele ser desarrollado en un largo período de tiempo, lo que contribuye a la pérdida de interés que mencioné antes. Este producto es el hiper-mercado.
Por otro lado, está el enfoque de partir el "problema" en pedazos, el clásico "divide y vencerás" (que muchas veces olvidamos al gestionar proyectos). La idea es desarrollar pequeñas herramientas, especializadas a cada sector o tipo de usuario, y con independencia de las demás herramientas, sectores y usuarios. Este tipo de herramientas son más sencillas de desarrollar, tienen un público objetivo acotado, un tiempo de desarrollo más pequeño, y por lo tanto un riesgo menor de fallar como proyecto. Por otro lado, este enfoque agrega un elemento nuevo: es necesario pensar en estándares e interoperabilidad para que estas herramientas puedan compartir información para lograr una verdadera sinergia. Estas son las pequeñas tiendas donde cada uno encuentra exactamente lo que quiere y necesita.
Este segundo es mi enfoque preferido, ya que como gestores nos permite concentrarnos en un elemento acotado a la vez, y nos permite hacer lo mejor en cada uno, a la vez que no perdemos de vista el proyecto global.


El éxito del proyecto no debería medirse en cantidades de usuarios o registros

Muchos gestores, para mostrar el éxito de sus proyectos muestran resultados numéricos como la cantidad de usuarios, la cantidad de registros clínicos, la cantidad de prescripciones electrónicas que fueron hechas, etc.
Si bien esos valores nos sirven para medir niveles de uso (cosa que se debe hacer frecuentemente), el éxito de un proyecto no se debería medir en esos términos, sino que debería medirse en los términos de "cómo ayudaron los productos del proyecto en alcanzar os objetivos organizacionales (tanto clínicos como de gestión)". Recordemos que estos proyectos son herramientas para lograr objetivos, y que sin estrategias organizacionales y objetivos de mejora estos proyectos no existirían. Por lo tanto deberíamos preguntarnos cosas como: con estas herramientas ¿cómo se aumenta la calidad de la asistencia a los pacientes? o ¿cómo se mejora el uso de recursos limitados?


Como siempre: ¡sus comentarios son muy bienvenidos!

Hasta la próxima.

19 de julio de 2011

Modelado de procedimientos con openEHR

Este es otro excelente post de la Dra. Heather Leslie, donde adjunta una presentación que describe el modelado de los procedimientos clínicos mediante arquetipos openEHR. Personalmente me gusta mucho esta forma de modelado, porque ayuda a que quede plasmado en el registro clínico todo el proceso de instrucciones/órdenes y las acciones que se llevan a cabo para dichas órdenes.

El modelo de instrucciones y acciones puede encontrarse aquí.

13 de julio de 2011

Optimizacion de datos demograficos: buscando la herramienta perfecta

Muchos de los colegas que siguen este blog ya saben que le he dedicado más de un post al tema de los datos demográficos. Creo que muchos de los que nos hemos topado con proyectos de informatización de cierta embergadura en instituciones sanitarias, sabemos que aunque los proyectos apunten a la "capa clínica", debemos prestar mucha atención a la "capa demográfica", porque es ahí donde estará la información para indizar correctamente los registros clínicos.

Hoy estuve pensando en los problemas que pueden causar los datos demográficos incorrectos o incompletos, y en las funcionalidades que debería tener un sistema informático de auditoría para resolver esos problemas. Si bien el sistema perfecto no existe, es bueno de vez en cuando parar un segundo y pensar en cómo sería la herramienta perfecta para nuestra organización. Aunque no se pueda construir la herramienta de forma inmediata, creo que esta es la única forma de saber hacia dónde se debe ir.

Aquí están algunas notas mentales de lo que para mí debería hacer el sistema perfecto:
  1. Ejecución de algoritmos:
    1. Detección de datos faltantes
    2. Detección de datos incorrectos
    3. Detección de duplicados
  2. Presentación de informes para el auditor
    1. Muestra problemas detectados
    2. Muestra primero los casos con más prioridad a resolver
    3. Permite acceder a las funcionalidades de resolución de problemas y optimización de datos
      1. Completar datos faltantes
      2. Corregir datos erróneos
      3. Resolución de duplicados (unificación de identidades)
      4. Agregar relaciones familiares (p.e. padre-hijo) 
  3. Registrar información de feedback

1. Toda herramienta para gestión y auditoría de datos demográficos debería contar con al menos estos 3 grupos de algoritmos. Los algoritmos para detección de datos faltantes, por ejemplo se fijan si el registro de una persona carece de un medio de contacto telefónico, o si falta registrar el segundo apellido. Los algoritmos para detección de datos incorrectos, pueden por ejemplo verificar el sexo a partir del nombre de la persona, un caso de error podría ser si para el nombre Carlos se tiene registrado sexo Femenino. Y los algoritmos para detección de duplicados, ya los he cubierto en artículos anteriores [1, 2].

2. Los problemas detectados deben ser revisados por una persona que pueda auditar los registros. Muchas veces se cae en el error de querer crear el sistema perfecto que detecte y resuelva todos los problemas, pero en este caso lo mejor es tener un sistema con la inteligencia suficiente para detectar problemas y mostrarlos, y que una persona sea la que los resuelva. Para resolver los problemas, muchas veces esta persona va a tener que ponerse en contacto con la persona a la cual pertenecen los registros con errores, para obtener la información correcta desde la fuente. También se pueden aprovechar las instancias en que la persona viene a atenderse, para solicitar que verifique su información. Una parte importante en este proceso es la de resolución de registros duplicados, porque puede implicar que se deban unificar también registros clínicos. La otra parte importante es la de registrar las relaciones familiares entre pacientes, porque esto permite asociar historias clínicas familiares, y es útil para detectar problemas hereditarios a tiempo. ¡Los datos demográficos también sirven para mejorar la salud de las personas!

3. Cuando los problemas detectados, no son realmente problemas (las computadoras son tontas), se debe dar información al sistema para que éste sepa que esos no son problemas. Entonces, el sistema va "aprendiendo", y en la próxima detección de problemas, no los vuelve a marcar como tales. De esta forma, se va tendiendo hacia el óptimo del cero problema. Pero, como sabemos, este tipo de sistema gestiona datos que están en constante modificación: hay nuevos pacientes, se dan de baja otros, se corrigen datos, se ingresan nuevos duplicados, etc., por lo que este es un proceso que nunca termina, y se debe volver al punto 1 con una frecuencia que cada organización debería estimar.


¿Qué les parece? ¿Qué agregarían?

10 de julio de 2011

Marco conceptual para proyectos de informatizacion en salud

En mi artículo anterior informatización en salud ¿por dónde empezar? abrió una discusión muy interesante desde varios puntos de vista.

La primer conclusión que saqué de los comentarios fue que todos tenemos una idea distinta de lo que debe ser un proyecto de informatización en salud. Las diferencias pueden venir de la experiencia, de la formación, del estudio, etc, cada uno hace énfasis en lo que más le interesa/preocupa, algunos ponen énfasis en los temas relacionados con la gestión, otros con adaptarse a la forma de trabajo del médico y el equipo de salud, y otros están enfocados en la implementación concreta de herramientas (sobre todo los informáticos).

Estas diferencias me llevaron a pensar en una especie de marco conceptual, que sirva de punto común para que los distintos perfiles entiendan un mismo proyecto, y luego dentro de éste, cada uno puede definir su propia visión particular, basado en los factores antes mencionados.

Opino que si antes de empezar un proyecto, podemos saber que tipo de proyecto es y qué enfoque va a tener, la ejecución del mismo será mucho más sencilla, comparado con comenzar un proyecto sin tener una visión clara de qué tipo de proyecto es. Además esta clasificación de alto nivel podría servir para no errar el camino, y también para marcar objetivos particulares, para la planificación, para crear medidas de avance y cumplimiento en base el tipo particular de proyecto.

Aquí está el diagrama de clasificación del tipo de proyecto en base a lo que hablamos en el artículo anterior:


Lo que marca el diagrama son 5 niveles. Donde el nivel 0 debería estar predefinido, porque los proyectos de informatización en instituciones sanitarias deberían ser parte de la estrategia organizacional. De lo contrario, los proyectos de informatización serán un dolor de cabeza, porque habrá que remar contra la corriente cada vez que se necesite tomar una decisión importante, debido a que los habrá que convencer a los tomadores de decisión cada vez. Con el proyecto como parte de la estrategia organizacional, serán los propios tomadores de decisión quienes apoyen el proyecto antes inclusive de vislumbrarlo.

Los niveles de 1 a 4 marcarán fuertemente el tipo de proyecto. El nivel indica a grandes rasgos las tareas necesarias a realizar en la parte de planificación y relevamiento (mucho antes de comenzar a desarrollar una herramienta informática). A medida que subimos de nivel, las tareas serán más grandes y compleja, por lo que será un proyecto de mayor porte, pero también de mayor impacto. Además, cuanto mayor sea el nivel, los resultados del proyecto estarán más integrados a la organización, o sea que se adaptarán de mejor forma al funcionamiento de la organización y a su cultura, por lo que tendrá una menor resistencia y una mejor adopción por parte de los usuarios.

Luego de definir el nivel en el que será ejecutado el proyecto, el arco iris representa el enfoque que tendrá el mismo. Este enfoque estará basado fuertemente en la forma de gestión de la propia institución. En general las instituciones usan un nivel de gestión básico economista, orientado a las transacciones monetarias y a la contabilidad. Si bien esta forma de gestión es la más común, aunque no siempre la más apropiada, los proyectos de informatización en salud que estén marcados por este enfoque tendrán grandes problemas en su ejecución. Esto se debe a que los usuarios de las herramientas que cree el proyecto no serán las mismas personas que gestionan la institución, y desde la parte asistencial se puede percibir que están usando una herramienta que no se ajusta a sus necesidades. En este caso puede convenir partir en dos el proyecto, haciendo un proyecto más pequeño orientado a los RRHH o a los procesos, más adaptado a las necesidades del personal asistencial, y otro proyecto orientado completamente a la gestión. El resultado de este proyecto será una herramienta que permita a los gestores "espiar" lo que pasa en la parte asistencial, y vincular a esos actos toda la información económica y contable que necesitan.

El enfoque en los RRHH sería cuando se quiere optimizar el trabajo de cada persona o rol, de modo de aprovechar al máximo el tiempo y el aporte de cada profesional a la institución. El enfoque en los procesos es el que busca optimizar procesos complejos donde intervienen múltiples personas o roles, buscando un óptimo global para cada proceso.

Y el enfoque orientado a los resultados, es el que busca optimizar el producto de la institución: el paciente sano o "La salud". Aún hoy existen muchas instituciones sanitarias que no saben qué producen, esto mismo debe especificarse en el nivel 0. Esto también puede dar para otro artículo porque es un tema muy debatido. Mi opinión es que dependiendo de la forma de gestión, un profesional dirá que el producto es el acto médico (enfoque economista), y como comentaba antes, otros dirán que es el paciente sano o "La salud" (enfoque orientado a los resultados).

Ahora que sabemos exactamente qué tipo de proyecto tenemos, el último elemento del diagrama es la ejecución del proyecto. Esto incluye las tareas de planificación, relevamiento, análisis, diseño, programación, pruebas, puesta en producción y seguimiento posterior.

Seguramente faltan muchos puntos a considerar para tener un buen "marco conceptual" para los proyectos de informatización en salud, sus opiniones son muy bienvenidas. Hasta la próxima.

24 de junio de 2011

Informatización en instituciones sanitarias

Informatización en instituciones sanitarias ¿por donde empezar?

He estado estudiando este tema desde hace tiempo y parece no haber una forma estándar o algún patrón que nos indique por donde tienen que empezar los procesos de informatización en las instituciones sanitarias, siempre pensando en el área clínica, no en el área administrativa que ya está informatizada.

Lo que pude detectar es que hay dos grandes formas de hacerlo, una es orientarse a los registros y otra es orientarse a los procesos. La primera creo que es la más común: el equipo de desarrollo analiza los registros que se realizan en la institución, y desarrollan un sistema que incluye esos registros de forma electrónica. La segunda forma es un poco más profunda y no tan común: consiste en analizar los procesos de la institución, saber qué se hace, quién hace qué, para luego llegar al nivel del registro, y saber quién registra qué y cuándo.

En el medio hay matices entre una y otra punta, aunque también existe una tercer opción o nivel, el cual incluye el análisis del sistema de información de la institución, esto es: la forma en que la información fluye dentro de la institución, quienes la generan, quienes la consumen, quienes la trancan, que dependencias de información existen, etc. Esto sería considerando cualquier tipo de información de salud, transmitida en cualquier medio: señales de humo, habla, teléfono, email, sistemas informáticos, etc.

Lo que noto es que muchas de las empresas proveedoras están en el nivel 1, el de análisis de registros, y esto es un problema para las instituciones. Lo otro que noto es que las instituciones tampoco están preparadas para los niveles 2 (análisis procesos) y 3 (análisis de sistemas de información), porque no hay definiciones formales de los procesos, y menos de los sistemas de información.

Lo que si he detectado, es que podemos generar un marco de evolución, donde se puede mostrar la madurez del proceso de informatización, formado por los 3 niveles antes mencionados. Donde cada nivel debe lograrse sobre el nivel anterior. Y esto pienso que no solo implica hacer más preguntas a la hora del análisis de la situación de la institución, pienso que implica un conocimiento profundo del área de la salud y del funcionamiento institucional.

Para concluir, creo que en un futuro cercano la realidad será otra. En principio porque vamos a tener la experiencia de varios proyectos, exitosos y fracasados. Lo segundo es que vamos a tener más gente formada en el área específica de la Informática Médica, con una mirada del problema desde la informática y desde la medicina. Esta mirada mixta es crucial para entender los problemas de la salud y la cultura de las instituciones (y no morir en el intento).

En un próximo artículo, trataré de comentar un proceso que desarrollé para el análisis de las instituciones sanitarias, orientado a los procesos (nivel 2), para lograr una herramienta informático adaptada a la cultura y forma de trabajo de cada institución.

7 de junio de 2011

¿Cuando es bueno no usar estandares internacionales?

El título de este post es un poco contradictorio con el trabajo que hago a diario. Mi trabajo consiste en el modelado e integración de distintos sistemas de información, y detectar oportunidades de aplicación de estándares internacionales.

A veces mi tendencia a querer aplicar estándares cansa un poco a mis colegas y proveedores, que quieren hacer las cosas rápido y a medida. Muchas veces, sobresalen los argumentos de las ventajas que tiene utilizar uno o más estándares para implementar determinada funcionalidad, sobre todo ventajas a mediano y largo plazo, como la capacidad de integrar otros sistemas sin tener que trabajar más, o de hacer que el sistema sea más fácil de adaptar a requerimientos futuros, etc.

Pero también me gusta pararme del otro lado y pensar cómo sería la solución si no aplicara tal o cual estándar, porque tampoco soy un fundamentalista de la estandarización (aunque algunos piensen lo contrario jeje).

Entonces ¿vale la pena usar estándares para todo, y todo el tiempo?. La experiencia y algunos colegas y amigos, me han demostrado que la estandarización tiene sus límites, y que muchas veces la utilización o no de estándares, depende más del contexto que del problema a resolver.

Por ejemplo, el Dr. Sergio Montenegro, director del Depto. de Informática Médica del Hospital Madariaga de Misiones, Argentina, me contó sobre el proyecto que están llevando a cabo a nivel provincial para tener una Historia Clínica Electrónica única. Mientras él me contaba los pormenores del proyecto, yo me imaginaba una gran cantidad de sistemas, interactuando entre sí, con muchas comunicaciones y muchos estándares en el medio. En ese momento, Sergio me contó que sería un solo sistema en un único datacenter el que daría soporte a la HCE provincial, y toda la complejidad desapareció. Es verdad que el enfoque centralizado tiene sus desventajas, pero son compensables con soluciones técnicas, de procesos o de negocio.
Entonces, para este tipo de proyectos, los estándares de comunicación casi desaparecen, porque toda la comunicación es interna. Igualmente, existen múltiples estándares que son aplicables a la interna del sistema, como estándares de contenidos (CIAP-2, CIE10, Snomed, etc), estándares de modelo/arquitectura (openEHR) o estándares para documentación clínica (HL7 CDA, ASTM CCR, ISO 13606, etc).
También es claro que no en todas las regiones tienen las cosas tan claras como en Misiones, por ejemplo, en Uruguay, aunque solo tenemos 3.5M de habitantes, que haya un solo sistema único sería imposible, tanto a nivel nacional, o incluso departamental con unos cientos de miles de personas.

Otro ejemplo podría ser cuando se tiene una red de hospitales y en cada uno se utiliza un sistema de registro clínico distinto, y desean crear una HCE única para sus pacientes. En este contexto lo que uno gritaría HL7! de entrada, pero dependiendo del proyecto, tal vez HL7 no sea una buena opción. Por ejemplo, si se sabe que solo esos hospitales formarán una red clínica, con su HCE única, es posible desarrollar un estándar para implementar en esa red. Obviamente, un estándar hay que usar, pero no necesariamente debe ser uno internacional. Por ejemplo, el estándar a desarrollar puede estar basado y adaptado a los modelos de negocio, los modelos de atención y los sistemas de información presentes en los hospitales y en la región, con la diferencia de que si se usa HL7 se deberá perfilar el estándar internacional a su uso local. La creación de un estándar local específico para el intercambio de cierta información puede hacerse mucho más rápido que el perfilamiento de un estándar internacional. Igualmente, tener conocimiento de los estándares internacionales puede dar buenas pautas para el desarrollo del estándar local.

Con esto tengo un ejemplo concreto. En el proyecto FEMI Salud Digital donde trabajo ahora, desarrollé un Índice Maestro de Personas (IMP) que guarda un conjunto mínimo de datos patronímicos de pacientes, con el objetivo de poder linkear Historias Clínicas Electrónicas a nivel nacional entre 23 instituciones en distintos departamentos de Uruguay. Los servicios que provee este IMP están basados en los perfiles IHE PIX y PDQ, pero están implementados usando Web Services REST, en lugar de mediante Web Services SOAP, y en lugar de usar mensajería HL7 PA, utilizan mensajería XML a medida. La estructura de la mensajería XML es muy parecida a la estructura de los mensajes HL7v3, pero mucho más simple. En definitiva es mensajería XML sobre HTTP.

Ejemplos pueden haber mil, pero el mensaje es que quiero dejar es: siempre deberíamos tener 4 o 5 estándares internacionales como referencia (p.e. openEHR, HL7, DICOM, CIE10, CIAP-2), pero debemos considerar el contexto de cada proyecto para saber si vale la pena perfilar los estándares internacionales o crear nuevos estándares locales. La segunda opción solo se debería tener en cuenta, si primero se tienen en cuenta los aspectos clave de los estándares internacionales. Desarrollar un estándar local sin una referencia externa es un error conceptual a no ser que realmente no exista la referencia (cosa que no ocurre a menudo, lo que si ocurre mucho es que no se buscan referencias y se quiere reinventar la rueda a cada paso).

28 de mayo de 2011

Ideas sobre escritorio médico electrónico

Con el colega Sergio Retamar de Misiones, Argentina, empezamos a hablar de lo útil que es tener un escritorio médico integrado a los sistemas de historia clínica electrónica, justamente para ayudar a organizar el trabajo de los médicos y otros miembros del equipo de salud, la comunicación entre profesionales y la comunicación institucional, entre otros temas. Este hilo estará dedicado a proponer ideas de lo que debería (o no) estar dentro de un escritorio médico electrónico.

Con Sergio tuvimos un intercambio fuera de la lista para llegar con algo de valor al iniciar la discusión. La idea es que entre todos podamos aportar para llegar a una lista de requerimientos de lo que podría ser más útil. Esto luego puede volcar en cualquier sistema de historia clínica que desee desarrollar el concepto de "escritorio médico electrónico". Se aceptan sugerencias aquí.

Objetivos:
  • Debe haber información de valor para los médicos. 
  • Debe haber información contextual:
    • A su trabajo inmediato
    • Al estado de sus pacientes
    • A su especialidad o área de interés
    • Al departamento/institución donde se desempeña
    • A su formación pasada, presente y futura

Contenido:

Trabajo inmediato:
  • Acceso a turnos de pacientes: lista de pacientes que según los  registros del sistema (agenda) estarían esperando y próximos a  presentarse para su atención. Al seleccionar un paciente (turno)  debería acceder a su historia clínica.
  • Estudios solicitados: pendientes y resultados de los pedidos, de cualquier paciente/de pacientes en su agenda de turnos.
  • Acceso a la administración de sus agendas: cambio de horarios, reasignación de turnos, etc.
  • Búsqueda de pacientes: en la base de pacientes de la institución o red asistencial.
Comunicación:
  • Comunicados institucionales.
  • Mensajería interna entre médicos.
  • Noticias en prensa: relacionadas con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.
  • Próximas reuniones: comités hospitalarios, gremiales, reuniones de directiva, etc.
Capacitación, investigación, eventos:
  • Noticias en revistas científicas/trabajos científicos: relacionadas con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.
  • Congresos y eventos: relacionadas con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.
  • Cursos: relacionados con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.
Otros:
  • Estadísticas: sus estadísticas de uso del sistema, de su registro clínico, de sus errores cometidos, de cumplimiento de metas/objetivos, de su performance, de sus costos de atención, etc.
  • Acceso a su correo electrónico institucional.
  • Acceso a buscadores preconfigurados.

Idea sobre información contextual: quizás se podrían generar alertas (como se puede hacer en google: http://www.google.com/alerts) según los temas e interés del profesional (especialidad, patologías frecuentes en sus pacientes) y mostrar como noticias, presentaciones,  publicaciones destacadas.

Parece muy adecuado que el contenido pueda ser opcional y configurable por cada profesional, permitiendo agregar lo que sea de mayor interés para cada usuario.

¿Que les parece?

4 de abril de 2011

Nueva version de OpenEHR-Gen Framework

Estamos muy contentos de anunciar la liberación de una versión mejorada de OpenEHR-Gen Framework, la herramienta que ayuda a crear sistemas de Historia Clínica Electrónica usando estándares internacionales como openEHR, HL7 CDA y CIE 10. La nueva versión está disponible aquí: http://code.google.com/p/open-ehr-gen-framework

Lo interesante (o distinto) de este proyecto, es que todo el registro clínico es generado de forma dinámica y "al vuelo", en base a arquetipos que modelan conceptos clínicos (presión arterial, escala de Glasgow, frecuencia respiratoria, etc), y plantillas que indican cómo se debe mostrar cada formulario. Tanto los arquetipos como plantillas pueden ser definidos por el equipo de salud, y la herramienta genera el registro a partir de lo que ellos definen, sin necesidad de programar. 

OpenEHR-Gen Framework es 100% código abierto y gratuito. Se agradece la difusión del mismo.

Aquí se pueden descargar algunas capturas de pantalla de la historia clínica del dominio de trauma: http://www.subirfacil.com/files/1BIEYWYQ/capturas_openehr-gen.zip

Este proyecto fue concebido desde nuestra tesis de grado, el cual también tenía integración del estándar DICOM (integración con imagenología digital) y de la especificación IHE PDQ (consulta de datos demográficos): http://informatica-medica.blogspot.com/2010/12/documentacion-de-mi-pr...

Algunas presentaciones y documentos sobre el proyecto que pueden ser de interés:

Los principales cambios con respecto a la versión anterior son:
  • Actualización del framework de desarrollo: Grails Framework de v1.1.1 a v1.3.7
  • Agregamos la implementación de la clase Folder del modelo de referencia de openEHR. La usamos para modelar distintos dominios de registro como "emergencia", "ambulatorio", "prehospitalario", etc., los registros de cada dominio van al mismo Folder.
  • Se mejoró el diseño de la interfaz de usuario para que sea más compacta, y se mejoró la generación dinámica de la interfaz de usuario.
  • Se agregó soporte a la directiva de interfaz de usuario "type=smallText" para los templates, que sirve para mostrar inputs de texto pequeños para los nodos DvText de los arquetipos. Antes se mostraban controles textarea/memo para todos los DvText aunque fueran para ingresar textos pequeños.
  • Se cambió el cierre del registro clínico por verificación dinámica de condiciones, ahora el registro debe ser explícitamente cerrado y firmado por el médico. Esto da mayor flexibilidad para la definición de nuevos tipos de registros.
  • Se agregó la validación de restricciones de ocurrencias sobre nodos de tipo ITEM_SINGLE, que no estaba implementado. Se corrigieron errores pequeños y se limpió el código.

Cualquier consulta o comentario es todo bienvenido.
Estamos completamente abiertos a la  colaboración.

9 de febrero de 2011

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