23 de octubre de 2010

OpenEHR el estándar abierto para historias clinicas electronicas

Este es el primer artículo de la serie sobre estándares en Informática Médica.

El objetivo de esta serie es presentar distintos estándares desde un punto de vista práctico y muy crítico, ya que muchas veces nos llega mucho ruido de quienes promueven sus propios estándares, pero no contamos con una mirada independiente que nos ayude a entender si nos quieren "vender un buzón" o si realmente usando lo que nos dicen podemos solucionar los problemas que plantea la Informática Médica.


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


Un posible punto de introducción al tema: http://es.wikipedia.org/wiki/OpenEHR

OpenEHR en pocas palabras:
  • Estándar abierto que define un modelo de información y un modelo de conocimiento clínico.
  • Propone el enfoque de sistemas informáticos "orientados a la gestión del conocimiento clínico".
  • Objetivo: ayudar a crear sistemas "semánticamente abiertos", durables en el tiempo, y económicamente viables.

Explicando las "pocas palabras":

Estándar abierto: es generado, mantenido, probado y validado por una comunidad de usuarios dividida en dos grandes grupos: los expertos clínicos y los expertos en TICs (Tecnologías de la Información y las Comunicaciones). Para formar parte de la comunidad no es necesario pagar, toda la información es libre y para participar en las discusiones solo es necesario registrarse en su lista de correo.

Define un modelo de información clínica:

El modelo de información de OpenEHR es una especificación UML (orientada a objetos), y es la parte del estándar que debe implementarse dentro del software. La principal característica es que es un modelo genérico, es decir, que permite representar toda la información que se genera en la asistencia médica, pero no especifica la semántica de cada concepto clínico particular, solo contiene conceptos clínicos generales, como son: observaciones, evaluaciones, instrucciones y acciones. Luego profundizaremos más en los detalles del modelo de información clínica.

Define un modelo de conocimiento clínico:

El modelo de conocimiento de OpenEHR es básicamente una especificación de unos artefactos llamados "arquetipos". Los arquetipos son simples archivos de texto plano, que cumplen una sintaxis llamada ADL (Archetype Definition Language). El objetivo de los arquetipos es representar conceptos clínicos particulares y residen fuera del software (al contrario del modelo de información que representa conceptos clínicos generales y reside dentro del software). Los conceptos clínicos particulares son representados como un conjunto de restricciones sobre el modelo de información genérico. Luego veremos algún ejemplo.

Orientación a la gestión del conocimiento clínico:

La idea de que los conceptos clínicos particulares residan fuera de la aplicación de software, es en si un cambio de paradigma. Hoy en día, los Sistemas de Información en Salud son fabricados de forma que el conocimiento clínico está definido de forma "dura" en el software. Esto quiere decir, que si cambia el conocimiento clínico que maneja el software, se debe cambiar la aplicación de software (en el sentido que necesita adaptarse a los cambios en el conocimiento clínico). Esto hace que cada cambio sea muy costoso.

Por el contrario, si el conocimiento clínico es definido y gestionado por fuera del software, como la aplicación de software es genérica, los cambios en el conocimiento no repercuten en el software, ahorrando costos innecesarios. Este paradigma de "gestión del conocimiento clínico" no solo tiene ventajas en ahorro de costos, si no que puede tener implicancias más profundas en los proyectos de TICs en salud.

Hoy, para crear un sistema de software en salud, un grupo de analistas informáticos tiene una o varias reuniones con un grupo de médicos que les expresan sus necesidades (requerimientos sobre el software). La experiencia indica que este proceso es en general infructuoso. Por ejemplo, una historia que se repite es: cuando el grupo de analistas está convencido de que ha extraído todos los requerimientos, se comienzan a construir prototipos. Una vez finalizados, éstos les son mostrados a los médicos, los cuales comentan cosas como "esto no es lo que pedimos", "esto no me sirve", "yo no te dije esto", o directamente "esto es una porquería". Entonces se tira todo y se vuelve a empezar. Esto se repite unas cuantas veces, hasta que se logra lo que los médicos quieren. La regla del dedo indica: los informáticos no entienden a los médicos y viceversa. Uno de los problemas surge de que en este proceso, los informáticos deben gestionar el conocimiento clínico extraído de los médicos, tarea para lo que no estamos preparados (no somos expertos en el dominio clínico, los médicos si).

La pregunta clave: ¿porqué no hacer algo que permita que los médicos puedan gestionar el conocimiento clínico directamente sin tener que pasar por los analistas? ¿no nos ahorraríamos muchos dolores de cabeza, tiempo y dinero?. Bueno, esta es la clave de la "orientación a la gestión del conocimiento. Dado que el conocimiento clínico es definido fuera del software, si pudiéramos enseñarles a los médicos a usar una herramienta para generar arquetipos, los médicos podrían definir el contenido de la Historia Clínica Electrónica sin siquiera tener que hablar con un informático. Mientras, con el tiempo ganado, los informáticos podemos crear mejores sistemas de software, más genéricos y más inteligentes, que permitan cargar los arquetipos que definen los médicos y generar el sistema de información en base a ellos.

Esto tiene varias implicancias. Primero, es el médico quien decide que poner o no poner en un arquetipo, por transitiva, está decidiendo que va y que no va en la historia clínica. Por lo tanto, se evitan las quejas de que el sistema no registra lo que el médico necesita, porque está definiendo justamente lo que necesita. Segundo, se le da a los médicos un rol más preponderante en los desarrollos de TICs en salud. Con el enfoque actual, los informáticos hacemos "uso" de los médicos solo cuando los necesitamos, luego ellos pierden visibilidad del proyecto. Tercero, debido a la satisfacción del médico por haber sido él quien creó la historia clínica y por haber participado activamente en el desarrollo, se facilita el cambio cultural que involucra la inserción de las TICs en salud, evitando rechazos y ganando adeptos que pueden contagiar a los demás en usar el sistema. De esta forma deja de ser un proyecto informático y pasa a ser un proyecto médico.

Sistemas semánticamente abiertos

Los arquetipos son definiciones semánticas de conceptos clínicos particulares. Esto quiere decir que cada arquetipo expresa un concepto clínico, junto con su propósito, para qué se debería usar, para que no se debería usar, cual es su estructura interna, qué vínculos con codificaciones y vocabularios controlados tiene, entre otros elementos.

Los arquetipos pueden traducirse, esto quiere decir que puedo definir un arquetipo junto a sus contexto expresado en múltiples idiomas. Un arquetipo puede compartirse, de modo que si defino un arquetipo para el concepto "presión arterial" en español, puedo traducirlo a inglés y enviárselo a una institución sanitaria en Inglaterra, y ellos podrán entender lo que representa ese arquetipo. Incluso, sus sistemas informáticos podrían hacer uso de ese arquetipo, de modo que si les envío información referente a la presión arterial de un paciente desde Uruguay, ellos la podrían validar e interpretar utilizando el arquetipo.

Sistemas durables en el tiempo:

Con el enfoque de "gestión del conocimiento clínico", el conocimiento clínico reside por fuera de la aplicación de software, por lo tanto, a medida que avanza la medicina, el conocimiento puede gestionarse y actualizarse, sin necesidad de modificar la aplicación de software. Por otro lado, las tecnologías cambian, y la aplicación de software podría modificarse sin necesidad de modificar el conocimiento clínico. Esto quiere decir que los procesos de gestión del conocimiento y de gestión del software son independientes. Es más, son ejecutados por roles distintos: expertos en el dominio clínico (médicos, enfermeras, técnicos) y expertos en TICs (ingenieros, analistas, programadores), respectivamente. De esta forma, aunque la tecnología cambie, el conocimiento y la información deben sobrevivir el paso del tiempo, lo importante es mantener estos durante toda la vida del paciente, y aún más tiempo (podríamos hablar de que la información clínica debe durar unos 120 años).

Sistemas económicamente viables:

Debido a que ya no es necesario que los analistas extraigan requerimientos y se creen prototipos que los médicos van a rechazar, simplificamos el proceso de desarrollo, y estamos ahorrando en tiempo y dinero. Gracias al enfoque de "orientación a la gestión del conocimiento", el software no necesita modificarse con cada cambio en el conocimiento clínico (que ahora es gestionado de forma independiente por los expertos en el dominio clínico), y considerando que el mayor costo de los proyectos está en el mantenimiento y adaptación del software, este costo se reduce enormemente.


Dentro del modelo de información genérico:

El modelo de información de OpenEHR es básicamente un árbol, donde la raíz de éste es la estructura de más alto nivel, llamada "composición". La "composición" puede ser vista como un formulario de registro en papel, el cual está formado por partes más pequeñas que se "componen" para crear la hoja de registro.

Esas partes más pequeñas son llamadas "entradas" de la historia clínica. Estas entradas no son campos donde se ingresan datos, si no que son grandes conjuntos de campos donde se ingresan datos, que a su vez tienen alguna relación entre ellos, esa relación está contenido en cada "entrada".

Para no hacer una descripción de todo el modelo de información, vamos a concentrarnos en el modelo de entradas, que me parece fundamental para entender tanto el modelo de información como el modelo de conocimiento. En la figura 1 podemos ver el proceso de resolución de problemas clínicos. En éste vemos que cuando un médico recibe a un paciente, lo primero que hace es observarlo, medirlo, preguntarle. La información que surge de esas observaciones, se debe registrar. Luego el médico realiza evaluaciones, plantea objetivos y planes de cuidado, esto en base a su conocimiento y a fuentes de conocimiento externas. Esta información de las evaluaciones también debe ser registrada. El paso siguiente es dar instrucciones, indicaciones, órdenes. Desde solicitar que se haga un estudio de laboratorio, hasta darle indicaciones al paciente en el alta. Por último, cerramos el ciclo con la ejecución de las instrucciones, lo que vemos aquí como "acciones". Si el paciente no es dado de alta, el ciclo vuelve a ejecutarse. Todo debe quedar registrado.


Figura 1: proceso de resolución de problemas clínicos.

Indirectamente, lo que vemos es que toda la información clínica generada en la atención del paciente puede catalogarse en grandes clases, las cuales son: observaciones, evaluaciones, instrucciones y acciones. En la figura 2 vemos el modelo UML de estas clases. Lo central del diagrama, aunque parezca complejo, es ver que todas las entradas tienen una superclase abstracta "Entry". Luego tenemos dos subclases "Admin Entry" y "Care Entry", entradas administrativas y entradas de cuidado, respectivamente.Por último, dentro de las entradas de cuidado tenemos cuatro subclases "Observation", "Evaluation", "Instruction" y "Action". Lo que estamos viendo aquí es el corazón de la Historia Clínica Electrónica.

Figura 2: modelo UML de entradas OpenEHR

Algunos detalles del modelo de entradas. Podemos ver que una "instrucción" tiene varias "actividades" relacionadas. Esto modela que las tareas a realizar pueden ser complejas e involucrar varias actividades para ser realizadas, las actividades pueden verse como una lista de pasos para realizar la tarea. Por lo tanto, con una "instrucción" se podría modelar por ejemplo una guía clínica o un protocolo clínico.
A su vez, vemos que una "acción" puede tener relacionada los detalles de una instrucción, esto es para indicar que la acción fue realizada porque tal "instrucción" y tal "actividad" así lo indicaban. Por último, la "acción" también tiene asociada una "transición en una máquina de estados", esto sirve por ejemplo, en acciones que no son puntuales, si no que se ejecutan durante un período de tiempo (como dar una medicación durante 2 horas), para expresar que se comenzó a ejecutar la acción, se que finalizó, que se canceló, que se suspendió, etc. Todos esos son estados y están asociados a una máquina de estados con transiciones definidas, por ejemplo: no se puede cancelar la administración de un medicamento si todavía no se ha empezado a administrar.

Previamente comentábamos de que el modelo de información era genérico. ¿Pero donde está lo genérico? Imaginemos que necesitamos representar el concepto clínico "toma de la presión arterial". En el modelo de información no hay ninguna clase particular que represente ese concepto, por el contrario, existe una clase que agrupa todos los conceptos clínicos que sirven para medir cosas sobre el paciente, la "observación". Bien, entonces el concepto "toma de presión arterial" es una "observación", pero necesitamos definir particularidades para esta "observación" específica, eso lo hacemos con los arquetipos.


Ejemplos de conceptos clínicos particulares y con que clases del modelo de información se corresponden.
  • Toma de presión arterial: observación
  • Frecuencia cardíaca: observación
  • Frecuencia respiratoria: observación
  • Resultado de un estudio de laboratorio: observación
  • Evaluación de vía aérea: evaluación
  • Clasificación de gravedad del paciente (triage): evaluación
  • Evaluación de disfunción neurológica: evaluación
  • Diagnósticos: evaluación
  • Orden de estudios de laboratorio: instrucción
  • Indicaciones para el paciente: instrucción
  • Colocación de vía venosa central: acción
  • Administración de sustancias: acción

Uso concreto de OpenEHR: Open EHR-Gen Framework

En un año de trabajo, junto a mi colega Leandro Carrasco, hemos desarrollado una herramienta que implementa el modelo de información de OpenEHR. Esta herramienta toma arquetipos, o sea conceptos clínicos particulares, y genera automáticamente las pantallas de registro para que los médicos ingresen datos. También genera automáticamente las estructuras de información que se deben almacenar en la base de datos, a partir de los datos ingresados por los médicos. Además, valida automáticamente los datos ingresados por los médicos, contra las restricciones definidas en los arquetipos.

En definitiva, es un sistema de información para la salud, que se genera automáticamente a partir de lo que los médicos definan en los arquetipos. Este tipo de herramientas nos permite pensar en otras formas de construir los sistemas de información para el ámbito de la salud, en formas que se adapten a lo que el médico realmente necesita.

Además de que estamos hablando de sistemas dinámicos, que no necesitan cambios antes nuevas necesidades de registro por parte de los médicos. Son ellos quienes definen le registro a partir de los arquetipos. Estamos hablando de enormes ahorros potenciales tanto en tiempo como en dinero.

    Lo malo en OpenEHR:

    Esta es la sección donde me pongo duro con la crítica. Hasta ahora no he mencionado nada "malo" de este estándar, y hasta parece una excelente solución para muchos de los problemas que nos enfrentamos día a día quienes construimos sistemas de información en salud. La verdad es que OpenEHR agrega un montón de conceptos que realmente nos ayudan, pero nada es gratis.

    El proceso

    Vimos que el proceso de desarrollo puede simplificarse, en la medida de que los médicos, enfermeras y técnicos (expertos en el dominio clínico) definan sus necesidades mediante arquetipos. Para esto es necesario una capacitación, la cual no todos estarán de acuerdo en hacer. Muchos querrán seguir expresándole sus necesidades a los analistas informáticos. Esto es un problema, no directamente de OpenEHR, pero si de su aplicación práctica.

    Por otro lado, se necesita un proceso definido y controlado en cuanto a la creación corrección y actualización de los arquetipos. Si los médicos empiezan a definir sus arquetipos sin control, muchas veces se llegarán a inconsistencias. Por ejemplo, es necesario un comité médico que evalúe la calidad del arquetipo y que proponga mejoras, antes de integrarlo al registro médico. Una cosa que puede pasar es que un médico defina en parte de un arquetipo, un concepto clínico que ya está modelado con un arquetipo, en lugar de reutilizar el arquetipo existente.

    Limitaciones de los arquetipos

    Los arquetipos son buenos para expresar estructuras de información y restricciones puntuales sobre esa información, pero no es suficiente para expresar restricciones complejas como: si es un hombre entonces no puede estar embarazado. Las restricciones complejas pueden referenciar a varios conceptos clínicos (arquetipo) y no pueden ser definidas dentro de un arquetipo, por lo que se debe buscar una estructura de mayor nivel donde definirlas.

    Esto en sí no es un problema de los arquetipos, si no que los arquetipos no fueron diseñados para expresar esas restricciones complejas, que en cambio, si necesitamos en la práctica. Lo bueno es que teniendo los conceptos clínicos formalizados mediante arquetipos, la definición de esas restricciones complejas puede hacerse de forma sencilla, referenciando a esos arquetipos y sus nodos internos.

    Actualización de las herramientas

    Si bien la comunidad de OpenEHR provee un conjunto de herramientas libres y gratuitas, estas presentan algunos problemas que no parece que puedan ser solucionados a corto plazo. Obviamente, detrás de las herramientas hay personas, que muchas veces utilizan su tiempo libre en corregir y actualizar las mismas, y no reciben remuneración por hacerlo. Por un lado, es difícil exigirle algo a alguien en este esquema. Por otro lado, que estos proyectos queden estáticos, dificulta la introducción de nuevos adeptos al estándar, por que los desanima al momento en que prueban una herramienta y encuentran un problema.

    La clave es que al ser herramientas de código abierto, la comunidad debería participar en mejorar y actualizar el código, tal como pasa con otros proyectos de código abierto. Pero esto no está pasando con las herramientas de la comunidad de OpenEHR. Muchos esperamos que otro solucione los problemas y nos sentamos a ver que pasa. Este es un problema más de la comunidad que del estándar en sí.

    Estándar no oficial (de facto)

    OpenEHR no es respaldado por una organización como ISO o ANSI, organizaciones creadoras de estándares respetadas en el mundo, por lo tanto OpenEHR es visto por los burócratas como un estándar no formal, o simplemente como que no es un estándar. DICOM también es un estándar abierto, pero es soportado por toda la industria en el área de diagnóstico por imágenes, lo cual lo hace el "estándar de facto" en el área de la imagenología digital. Tal vez, con mayor soporte de la industria, OpenEHR pueda ser el "estándar de facto" para crear sistemas de información en salud.


    Conclusión

    OpenEHR es un muy buen estándar y propone soluciones a problemas reales. Su aplicación puede tener serias dificultades, pero con un retorno de inversión potencial enorme. Requiere si un cambio cultural, tanto en los médicos como en los informáticos, ya que requiere cambiar (mejorar) el proceso de creación de los sistemas de información en salud. Y muchos de los problemas que hoy tiene la difusión y adopción del estándar, son debido a una comunidad que pide más de lo que da, y como en el mundo nada es gratis, es bueno que si tomamos algo del estándar, aportemos algo a la comunidad: creando una herramienta, corrigiendo las que ya existen, difundiendo el estándar entre otros, haciendo cursos, exponiendo en congresos, creando sistemas basados en el estándar, publicando artículos en blogs, etc.


    Para ternimar, los invito a participar en el grupo de discusión en español sobre OpenEHR: http://groups.google.com.uy/group/openehr-es

    7 comentarios:

    1. Como siempre Pablo, tienes una gran facilidad de explicar cosas complejas de manera muy simple. Felicitaciones.

      Un aspecto importante que me gustaría destacar está relacionado a la intersección de datos estructurados con datos en texto libre. Este aspecto es extremadamente complejo de llevar a la práctica, cuando se habla con profesionales de la Salud. Mientras leía tu escrito pensaba:

      1) Capacito al Jefe de Cardiocirugía para que cree o elija sus arquetipos
      2) En el desconocimiento del tiempo que tarda cargar datos estructurados, él utiliza los arquetipos para lograr el mayor detalle posible de todo lo que se puede hacer en la especialidad
      3) El resultado: un formulario extenso estructurado, muy complejo de utilizar y que demanda mucho tiempo
      4) Quienes hacen el trabajo, rechazan el uso del arquetipo, o utilizan únicamente las 2 o 3 opciones que "encuentran factibles de completar en el escaso tiempo disponible".

      Ergo, las motivaciones de registro son la base de la ideación de estructuración de información. Aspecto complejo de la Informática en Salud que es difícil traspasar al médico tratante.

      Me encantaría que postees casos de éxito con OpenEHR que permitan entender cómo lograron sortear este gap entre lo que me gustaría tener estructurado y lo que estoy dispuesto a cargar estructurado.

      Saludos!

      Jano

      ResponderEliminar
    2. Muchas gracias Jano, se hace lo que se puede.

      Este es un buen tema para plantearlo y discutirlo en el grupo http://groups.google.com.uy/group/openehr-es.

      Lo que dices es cierto, pero hay varios aspectos grises que dejé afuera del artículo para no complicarlo.

      El primero, el objetivo del arquetipo es expresar conceptos clínicos en su forma más general y completa. Esto quiere decir, que si bien puedo hacer estructuras enormes adentro de los arquetipos, en diferentes contextos se usarán distintas partes de esa estructura. Concretamente, si ves los arquetipos definidos en la base de conocimiento global (http://www.openehr.org/knowledge/) vas a ver que la mayoría de los nodos son opcionales. Esto es útil, porque se puede usar el mismo concepto (arquetipo) en distintos contextos, algunos en donde se necesite registrar más información y en otros donde se necesite solo la información básica. Yendo, por ejemplo, al arquetipo de "presión arterial", en un contexto se podría registrar solo presión sistólica y diastólica, y en otro contexto también el estado del paciente (posición, factores que alteren la medida) y el protocolo (tamaño del manguito, lugar donde se hizo la toma, método, etc).

      Por eso es necesario un grupo que evalúe la calidad de los arquetipos, para que ningún médico pueda venir con estructuras complejas y no aplicables para otros contextos, excepto para el que lo quiere aplicar dicho médico. Igualmente, siempre se pueden revisar los arquetipos, encontrar problemas y resolverlos, ya que el ciclo de vida de un arquetipo permite correcciones a posteriori. Y esto, muchas veces, se verá en la práctica.

      Existe un elemento llamado "plantilla" (template) que sirve para indicar usos particulares de arquetipos generales. Es decir, es ahí donde se debería definir si se usan todos los nodos del arquetipo (la estructura enorme) o solo algunos pocos. Una plantilla se puede corresponder con una pantalla de registro. Referenciando todos los arquetipos que se utilizan para generar esa pantalla, pero solo haciendo referencia a unos pocos nodos de cada arquetipo.

      En nuestro proyecto (http://code.google.com/p/open-ehr-gen-framework/) lo que hicimos fue justo eso, pero hicimos un arquetipo especial que lo único que tenía era un campo de texto sin restricciones (libre), y ese se incluía en todas las plantillas, o sea, que en todas las pantallas de registro tenías un campo de texto libre por si no querías llenar la parte estructurada, o por si la parte estructurada no expresaba toda la semántica que el médico necesitaba. Un caso claro es que para los diagnósticos seleccionaban clasificaciones CIE 10, y al ser clasificaciones, pila de información se pierde, entonces siempre estaba el texto libre para registrar con toda libertar, y los CIE 10 para hacer análisis.

      Otro aspecto que influye es el cómo se construye el software, y de cómo este software genere la interfaz de usuario a partir del arquetipo. La interfaz se podrá generar como un campo de texto libre o como muchos campos y estructuras anidadas en pantalla, depende de como se diseñe la herramienta. No tienen porqué haber una correspondencia 1-a-1 entre un nodo de un arquetipo y un campo para llenar datos en pantalla, claro, si la correspondencia es 1-a-1, el desarrollo del software es más sencillo.

      El éxito es relativo, yo diría que OpenEHR es muy popular en la academia, y algo popular en la industria. En su portal puedes ver la cantidad de trabajos hechos acerca de OpenEHR y sus aplicaciones. Además puedes encontrar desarrollos hechos por diversas empresas, basados en distintos aspectos del estándar:

      http://www.openehr.org/shared-resources/publications/archetypes.html
      http://www.openehr.org/shared-resources/usage/commercial.html

      Aquí tienes los likns a los recursos resumidos: http://groups.google.com/group/openehr-es/web/4-gua-de-acceso-a-la-comunidad-internacional

      Un abrazo y gracias por siempre estar ahí para aportar y darle para adelante al blog.

      ResponderEliminar
    3. Este artículo de Heather Leslie complementa a la perfección lo comentado en mi artículo. En particular se centra en los arquetipos y en su rol para lograr una Historia Clínica Electrónica Estandarizada, Global e Interoperable:
      http://omowizard.wordpress.com/2011/02/18/anatomy-of-an-archetype/

      ResponderEliminar
    4. Un artículo muy interesante de lo mejorcito que he leído sobre OpenEHR. Muchas gracias por tomarte la molestia de explicar de un modo menos críptico lo que supone el este estandar. Aún así siendo médico y con ciertos conocimientos de informática, me resulta muy difícil asimilar estos conceptos de una forma práctica.

      ResponderEliminar
    5. Gracias Martín, tal vez estos recursos te ayuden a entender cómo se aplica el estándar en la práctica. El objetivo es normalizar la forma en la que se define el contenido clínico (lo que se registra en la HC), esto se hace mediante arquetipos, lo que no solo permite definir el contenido, si no que permite procesarlo por computadora y compartirlo entre distintos sistemas de HCE (esto sirve para lograr consistencia semántica en contenido clínico entre distintos sistemas de HCE).

      Aquí otros recursos:
      http://www.slideshare.net/pablitox/proyecto-traumagen-cais-jaiio-2010
      http://www.slideshare.net/pablitox/taller-open-ehr-cais-2010-pablopazos
      http://www.slideshare.net/pablitox/open-ehrgen-un-framework-para-crear-historias-clnicas-electrnicas
      http://www.slideshare.net/pablitox/historia-clnica-electrnica-de-trauma-con-acceso-a-estudios-imagenolgicos-digitales-presentacion-cais-2010

      ResponderEliminar
    6. Buenos dias. Quisiera hacerle una pregunta, según su planteaminto entiendo que cada médico por medio de los arquetipo define que información podría tener una EHR y así sucesivamente cada institución prestadora de servicios de salud haría lo mismo, en este caso que vocabulario médico como SNOMED, LOINC, CIE-10, son utilizados para especificar la información clínica ? como se garantiza que al diseñar arquitipos exclusivos para cada institucion, pueda haber interoperabilidad sintáctica y semántica entre EHR ?

      ResponderEliminar
    7. Buen día Camilo,

      Digamos que los arquetipos son un "lenguaje para definir la estructura de la historia clínica electrónica". Si bien cada médico o institución puede definir su propia estructura, hay metodologías y buenas prácticas que indican cómo hacerlo para no generar inconsistencias entre distintas instituciones. Por ejemplo tener repositorios globales y públicos de arquetipos: http://www.openehr.org/knowledge

      Sobre la terminología, los arquetipos pueden referenciar a cualquier terminología, vocabulario, clasificación, etc., pero no restringe el uso a una u otra terminología. Por otro lado, los arquetipos para poder ser utilizados se deben restringir utilizando especializaciones (otros arquetipos más específicos) o plantillas (agregaciones de arquetipos restringidos para usos locales). Esto garantiza que los arquetipos centrales son simples y genéricos, así cualquiera los puede usar garantizando interoperabilidad, pero para satisfacer requerimientos específicos locales se usan los elementos antes mencionados.

      Puedes encontrar más información aquí: http://openehr.org.es/cms2/display/openehr

      Y puedes realizar consultas o comentarios LinkedIn o Facebook, además de en el foro de la comunidad: http://openehr.org.es/foro/

      Feliz comienzo de año.

      ResponderEliminar