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
Entradas
No hay comentarios:
Publicar un comentario