CloudEHRServer de PoC a SaaS

Este es un resumen de mi experiencia en el área de la Informática en Salud, que describe las diferentes etapas que me llevaron desde la investigación a la prueba de concepto (PoC), hasta la creación de software como servicio (SaaS).

Mi viaje en la Informática en Salud comenzó en 2006. Un proyecto de investigación y desarrollo me llevó a conocer el estándar openEHR (http://openehr.org). En ese momento vi a openEHR como una panacea para crear sistemas de información en salud (SIS), ya que proponía soluciones para muchos problemas comunes en ingeniería de software, con un enfoque novedoso, al que no estaba acostumbrado. Se buscaba estandarizar los componentes de la  arquitectura y el modelo de información de *cualquier* SIS, y al mismo tiempo proveer un nivel de flexibilidad y mantenibilidad a largo plazo que no vi que se lograra en otros proyectos, ni usando las metodologías habituales. Se diseñaban los SIS de la misma forma que se diseñaban los sistemas de facturación. Y el cambio de paradigma capturó mi atención.

En ese momento supe que quería crear herramientas que ayudaran a los clínicos a mejorar la calidad de la atención, pero también quería construir sistemas mejores de los que existían. Las especificaciones de openEHR se veían geniales, y aprendí mucho estudiándolas. Pero desarrollar sistemas que cumplieran con las especificaciones era otro tema. Pronto comprendí que uno de los principales retos de implementar las especificaciones de openEHR en software era que no había una forma definida para desarrollar el repositorio de datos clínicos. En mi opinión, el repositorio de datos clínicos es el centro de cualquier SIS. De hecho esto es tan difícil que aún hoy es considerado como una barrera para la adopción de openEHR.

En 2009 me focalicé en el diseño e implementación de repositorios de datos clínicos. Probé distintas tecnologías, herramientas y técnicas propuestas por la comunidad de openEHR. Primero comencé probando soluciones *puras*, como la utilización de una base relacional o una documental, llegando a la conclusión que los enfoques *puros* no se adaptan bien a diferentes contextos de uso. Estaba buscando una solución de aplicación general. Luego probé enfoques híbridos, y luego de evaluar alternativas, pareció el enfoque apropiado para lograr una solución más flexible. Probé bases de datos JSON y XML, y enfoques relacional + XML/JSON. También diseños con esquemas estáticos y dinámicos (en un ambiente relacional, sería generar nuevas tablas cuando se necesitan almacenar nuevas estructuras de datos). Entre 2009 y 2011 en mi proyecto de fin de carrera de Ingeniería en Computación, logramos una solución con una base de datos relacional (pura) y esquema estático (no cambia cuando se necesitan almacenar estructuras nuevas, lo que ayuda mucho a la mantenibilidad conservando flexibilidad). Esto funcionó muy bien para una primer prueba de concepto.

En 2012 el código fue abierto y comencé a mantener el proyecto. Se llamó EHRGen. Si bien la solución funcionaba, no tenía mucha flexibilidad / expresividad para realizar consultas de datos. El objetivo era crear un esquema de datos más la funcionalidad que permitiera crear consultas de datos y ejecutarlas, sin necesidad de modificar el software o escribir código SQL. Entonces comencé a especificar estos requerimientos iniciales, siempre buscando compatibilidad con openEHR, mientras probaba alternativas. Cuando encontré un enfoque que funcionó, creé el proyecto EHRServer.

En un comienzo, el EHRServer sirvió para mostrar cómo funcionaban los repositorios de datos clínicos openEHR (recordar que esto es una barrera para la adopción de openEHR). El repositorio está basado en el modelo de información de openEHR (http://openehr.org/programs/specification/releases/1.0.2), pero sus contenidos son definidos y retringidos por artefactos de conocimiento llamados arquetipos y plantillas. Los arquetipos representan conceptos clínicos individuales como Presión Arterial, Frecuencia Cardíaca, Diagnóstico, Prescripción de Medicamentos, etc. Las plantillas  representan definiciones de documentos clínicos completos, y utilizan arquetipos para definir cada sección. Estos artefactos especifican las estructuras de datos, restricciones, terminología, definiciones semánticas (concepto, propósito, contexto de uso, etc). Un repositorio de datos clínicos openEHR debe soportar el almacenamiento y recuperación de cualquier estructura de datos definida por un arquetipo, y agregar nuevas estructuras no debería afectar al repositorio. Aquí es donde se puede percibir el poder de openEHR: el modelo de información es estándar y puede extenderse de forma indefinida.

El EHRServer evolucionó, liberé su código fuente para la comunidad, y lo utilicé en mis cursos (http://www.cabolabs.com/es/capacitacion) para explicar cómo utilizar openEHR en la práctica. En 2015 publiqué el EHRServer en la nube, en un servidor de OpenShift, donde fue utilizado para pruebas, evaluación, investigación y capacitación. Hoy tiene más de 300 usuarios registrados. El EHRServer evolucionó, muchas funcionalidades fueron agregadas desde aquella prueba de concepto inicial, y se convirtió en un producto de código abierto.

Hoy, en 2017, el EHRServer es una solución robusta, segura, y fácil de integrar con aplicaciones móviles, web o de escritorio. Creo que la nube es la plataforma ideal para el EHRServer, por lo que decidí lanzarlo en la modalidad de software como servicio (SaaS). Para esto he creado https://cloudehrserver.com. En la primera etapa del servicio buscamos asociarnos a empresas que deseen usar el EHRServer, invertir en su desarrollo y crecer con nosotros. Para esto tenemos el Programa de Beta Partners (https://cloudehrserver.com/beta_partners_program). Los Beta Partners recibirán capacitación, acceso temprano a nuevas versiones y documentación del EHRServer, soporte premium, acceso exclusivo a demos y sesiones de preguntas y respuestas, y recibirán descuentos en los cursos que damos desde CaboLabs.com

Los próximos pasos serán, primero establecer una base de Beta Partners que permita mantener y mejorar el servicio a corto plazo, y ayudarlos con sus proyectos utilizando Cloud EHRServer. Luego mejoraremos la infraestructura, agregaremos más funcionalidades y servicios complementarios a Cloud EHRServer.

Acompáñanos en este viaje, necesitamos tu ayuda. Por favor comparte esto con tus colegas.

Ing. Pablo Pazos Gutiérrez

Director

www.CaboLabs.com

www.CloudEHRServer.com

EHRServer: primer repositorio de datos clínicos openEHR, de código abierto y orientado a servicios

Estimados amigos,

Quiero compartir buenas noticias de nuestro EHRServer, el primer repositorio de datos clínicos, de código abierto, orientado a servicios, que cumple con las especificaciones de openEHR (http://openehr.org).

Les agradezco si pueden tomarse unos minutos para ver de qué se trata y compartirlo con sus colegas. Sobre todo me interesa recibir su retroalimientación, ideas y mejoras, para seguir avanzando con el proyecto.

Aquí encontrarán toda la información del proyecto, sus características, casos de uso y la guía técnica: http://cabolabs.com/es/proyectos

Para quienes deseen probar el sistema, por favor contáctenme y les paso las instrucciones.

Dentro de poco liberaremos la versión 0.6 de EHRServer que incluye un montón de pequeñas mejoras a nivel de interfaz de usuario, robustez y testing.

Para realizar consultas técnicas sobre EHRServer, contamos con nuestro foro técnico: http://cabolabs.com/forum/categories/ehrserver

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.

Documentacion de mi proyecto de grado

Estimados,

En esta ocasión me gustaría dejarles un recopilado de la documentación generada durante el transcurso de mi proyecto de grado. El mismo consistió en la creación de una Historia Clínica Electrónica para el registro de la asistencia médica de pacientes gravemente traumatizados, por ejemplo: accidentados en el tránsito, baleados, apuñalados, precipitados de grandes alturas, etc.

Introducción al proyecto

En este proyecto tratamos de balancear dos fuentes de requerimientos bien distintas, los que venían de la parte médica y los requerimientos del equipo de desarrollo (Leandro y quien escribe). Hubo una tercera fuente de requerimientos que venían de la contraparte informática de la institución donde atendían los médicos.

Los requerimientos de la parte médica apuntaban directamente al registro y a la estructuración para permitir el análisis posterior, o sea, que no faltara ningún dato y que los datos necesarios para calcular indicadores estuvieran bien estructurados para simplificar cálculos, agrupaciones y consolidaciones.

Por nuestra parte, buscábamos orientarnos hacia la aplicación de estándares cuando fuera posible. Por otro lado, buscamos optimizar el modelado del a información que nos proveían los médicos. Nuestra experiencia fue que ellos piensan en datos y variables independientes, en lugar de conceptos clínicos y estructuras, y parte de nuestro trabajo consistió en unir y relacionar esos datos y variables independientes en estructuras de más alto nivel, que tuvieran correspondencias con conceptos clínicos de la realidad. También tuvimos en nuestras manos las decisiones sobre las tecnologías a emplear.

Desde la contraparte informática, los requerimientos estuvieron orientados a la alineación con los desarrollos locales y los estándares que ya se habían implementado en la institución.

La institución asistencial es cuestión es el Hospital Maciel, el cual es un hospital público y es una de las principales puertas de emergencia del país en cuanto a los pacientes traumatizados. La contraparte médica estuvo integrada principalmente por el Dr. Fernando Machado y el Dr. Gustavo Sanchez, también participó el Dr. Gerardo Barrios, presidente de la UNASEV.

Resultados y conclusiones

Lo que logramos fueron varias cosas. Por un lado, un producto que permite registrar todo lo que pasa en la atención de emergencia de pacientes traumatizados, desde que ingresan a la emergencia, hasta que salen de esta. Una de las principales características es que este sistema tiene integrado el acceso a estudios imagenológicos digitales, así que un médico puede ver todos los estudios de imágenes de sus pacientes, a través de la misma historia clínica.

Otro resultado fue un framework genérico que sirve para crear diversos sistemas de HCE basados en arquetipos OpenEHR. En realidad el producto final fue desarrollado como una configuración particular del framework genérico. Aquí se puede encontrar toda la información relativa a este nuevo proyecto open source, creado luego de terminar la tesis.

Por otro lado se logró demostrar que la aplicación de estándares en diversos aspectos de una HCE es posible de realizar, en plazos limitados de tiempo y contando con poco recurso humano (el proyecto duró un año y 4 meses, y lo armamos desde cero entre dos personas). Los estándares y especificaciones que integramos son:

• openEHR: determinó gran parte de la arquitectura, diseño, modelo de información y modelo de conocimiento. Es el corazón del framework.
• DICOM: se utilizó para crear el componente de acceso a estudios imagenológicos, para poder ver imágenes diagnósticas desde la propia HCE web.
• CIE 10: se utilizó para la codificación de diagnósticos. Solo se utilizaron los códigos del capítulo XIX: Traumatismos, envenenamientos y algunas otras consecuencias de causa externa.
• CDA: se utilizó para la generación de documentos clínicos en base a la información registrada en el sistema, de esta forma, toda la información registrada en el sistema queda accesible desde otros sistemas intercambiando documentos HL7 CDA.
• IHE PDQ: se utilizó para poder consultar la base de datos de pacientes (que ya tenía la institución) desde nuestra HCE de trauma.

Material

A continuación dejo un link con toda la información del proyecto. Por un lado la entrega del proyecto (la tesis) está dividida en dos, los capítulos y los anexos. Luego está la presentación final del proyecto ante el tribunal evaluador. También encontrarán el paper y la presentación hecha en el CAIS 2010 donde hablé sobre el proyecto.

Actualización: dejé la documentación aquí: http://code.google.com/p/open-ehr-gen-framework/downloads/list


Cualquier pregunta o comentario, todo es bienvenido.

¡Feliz 2011!