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.