3. 1. Introducción
¿Cómo surge el framework?
• Proyecto de grado 2009-2010
• Traumagen: Historia Clínica Electrónica de Trauma con
Acceso a Estudios Imagenológicos Digitales
• Buscamos la aplicación de múltiples estándares
o OpenEHR: arquitectura, modelo de inf., modelo de conocimiento
o DICOM: imagenología digital
o HL7 CDA: repositorio documental
o HL7 PA / IHE PDQ: consulta a bases de pacientes externas
o OMS CIE10: clasificación de diagnósticos
• La aplicación de OpenEHR lleva al desarrollo de un
framework genérico para crear cualquier sistema de HCE
4. 1. Introducción
Resultados
• Desarrollo de un framework orientado a la gestión del
conocimiento clínico:
o Registro de trauma definido fuera del software
• Demás requerimientos desarrollados sobre el framework
6. 2. Problemas comunes en SIS
Análisis del dominio
• Surgen "conceptos clínicos":
o Se implementan de forma dura en el software
o Cambios en el conocimiento clínico, repercuten en todos los
componentes del sistema
o Cambios costosos
• Modelo de información se implementa a medida:
o Aplicación a otros contextos requiere adaptación
o Adaptaciones costosas
• No existen definiciones semánticas de los conceptos
clínicos:
o Impide la interoperabilidad semántica
• Los informáticos no somos expertos en el dominio clínico:
o Conceptos clínicos
o Terminologías
o Procesos asistenciales
7. 2. Problemas comunes en SIS
Ejemplos de conceptos clínicos:
• Signos vitales:
o Presión arterial
o Temperatura corporal
o Frecuencia cardíaca
• Imagenología:
o Orden de estudio
o Estudios imagenológicos (RM, ECO, TC, PET, ...)
o Informe radiológico
• Evaluaciones clínicas
o Vía aérea
o Exploración externa
o Diagnóstico
• ...
8. 2. Problemas comunes en SIS
Editor de formularios
• Solución rápida para hacer cambios al registro
o Forma indirecta de representar cambios en conceptos clínicos
• ¿Soluciona el problema?
o No define semántica de cada campo
o No define relaciones con otros campos
o No define restricciones complejas
o No se pueden compartir las definiciones entre sistemas
o No garantiza consistencia de los datos
• El problema no es la edición rápida de formularios:
o El formulario se deriva de los conceptos clínicos
Definir conceptos clínicos, no formularios...
o Montañas de plantillas formularios que nadie usa vs. un conjunto
acotado de conceptos clínicos reusables en distintos contextos.
9. 2. Problemas comunes en SIS
Problemática de múltiples deptos. en un mismo hospital
• Distintas necesidades de registro
• Distintos procesos asistenciales
• Registran la misma información (conceptos clínicos)
• Hoy: grandes sistemas integrales monolíticos
o En el futuro serán múltiples sistemas
o Cada uno especializado en un área
o Compartiendo la semántica de los mismos conceptos clínicos
o Actuando como una plataforma integrada pero distribuida (cómo
Internet) de información clínica capaz de:
ser consultada por cualquier actor en el sistema de salud
no serán necesarios los informes al MSP
se logrará transversalidad entre instituciones
longitudinalidad a la vida del paciente
y continuidad del cuidado
11. 3. Posibles soluciones
Infraestructura de información para salud
• Conocimiento definido y compartido entre actores
• Sistemas:
o pequeños
o especializados en un contexto
o hechos en base a componentes genéricos
• Servicios provistos por y consumidos por actores
12. 3. Posibles soluciones
Infraestructura de información para salud
• Se necesita normalizar el conocimiento, información,
protocolos y servicios:
o Múltiples estándares (analogía con Internet)
• Sistemas: (OpenEHR)
o Usan el conocimiento estandarizado y compartido (metadatos)
• Redes: (HL7)
o Entre los sistemas, para publicar y compartir información
• Servicios:
o Soporte de información para el SNIS, nexo entre los actores
o 1 clic para:
SINADI y otros informes
Reporte y control de enfermedades poblacionales
Cálculo de indicadores
13. 3. Posibles soluciones
Comencemos gestionando el conocimiento clínico en los
sistemas de información en salud:
• Arquetipos:
o Definiciones formales de contenido clínico
o Modelos de conceptos clínicos
• Templates:
o Perfilan arquetipos para su uso local
• Expertos en el dominio clínico
o Gestionan el conocimiento
• Expertos en TICs
o Crean sistemas basados en ese conocimiento
• Cambia el proceso de desarrollo:
o Doloroso proceso de análisis
o Costoso proceso de desarrollo
17. 4. El framework
Definición
• Framework o "marco de trabajo"
• Aplicación parcial, genérica, reusable:
o http://en.wikipedia.org/wiki/Software_framework
• Resuelve funcionalidades básicas
• Simplifica y acelera nuevos desarrollos
18. 4. El framework: arquitectura
• Capas: MVC + Servicios
• GuiGen: generador de GUI
• DataBinder: validador y creador de estructuras
• RM: modelo de información normalizado
• Base de conocimiento: arquetipos y templates
• CDR: repositorio de datos clinicos
19. 4. El framework: funcionalidades
• En función de la base de conocimiento:
o Generación automática de GUI
o Validación automática de datos
o Generación de estructuras y persistencia automática
• Generación de CDA incorporada
• Lo mínimo necesario para generar cualquier sistema de
información en salud:
o El sistema se genera automáticamente a partir de la base
de conocimiento definida por médicos, enfermeras y
técnicos.
20. 4. El framework: funcionalidades
• Internacionalizable / Localizable
o Todos los textos son traducibles y adaptables a culturas
locales (adaptabilidad a ≠ contextos)
21. 4. El framework: tecnologías
• Java Stack
• GRAILS Framework ( http://grails.org/ )
o Hibernate (Persistencia)
o Spring (MVC)
• GROOVY ( http://groovy.codehaus.org/ )
• MySQL
• IDE: Eclipse / NetBeans
• Selección de tecnología por necesidad de alta
productividad.
22. 4. El framework: estado actual y futuro
• Código abierto:
o http://code.google.com/p/open-ehr-gen-framework
• Creando la comunidad para desarrollo y difusión
o Presentado en el CAIS 2010
• Documentación disponible
• Armando hoja de ruta para el próximo año
o Mejoras y pruebas en contextos reales
o Bugs y problemas ya son conocidos (issue tracker)
• Prueba de fuego: crear 4 HCEs
o prehospitalario, emergencia, ambulatorio, internación
• Plugins:
o Integración DICOM, IHE, terminologías, ...
23. 5. Demo
• Pantalla:
o triage de trauma
• Template:
o INGRESO-triage
• Arquetipo:
o openEHR-EHR-EVALUATION.triage_trauma.v2
Modelo de información a medida: el costo de adaptación depende de lo adaptable del software, y esto depende de cómo se creó el software.
Sin definiciones semánticas computables, de los conceptos clínicos que maneja el software, no es posible lograr interoperabilidad semántica.
Cada dato necesita una definición de su propósito y rol en el registro, su relación con otros datos, restricciones que se deben cumplir, y las estructuras que soportan estos datos.
Aunque no seamos expertos en el dominio clínico seguimos gestionando conocimiento clínico, terminologías o procesos asistenciales.
Ejemplos de conceptos clínicos que pueden surgir en el análisis del dominio.
Semántica: qué representa, con qué propósito, cómo debe ser usado, que relación con otros datos tiene, etc.
Restricciones: en gral. se definen restricciones sobre un dato puntual, pero las restricciones en el mundo real son mucho más complejas y abarcan múltiples datos y estructuras.
Compartir: en general las definiciones de formularios son para un software determinado, no son exportables, y si son exportables, no existe documentación accesible que permita su uso por otros sistemas.
Consistencia: que un mismo dato no pueda ser representado de múltiples formas incompatibles.
Registran la misma información: en realidad registran información asociada a los mismos conceptos clínicos, la información en si puede contener más o menos datos, según en contexto.
Proyecto de código abierto, ya liberado.
La primer actividad de difusión se hizo en setiembre en Buenos Aires, en el Congreso Argentino de Informática Salud.
Estamos armando la hoja de ruta del proyecto, para ponernos objetivos claros de aquí a un año.
Ya existen registros de problemas y mejoras a realizar.
La prueba de fuego será la creación de 4 sistemas de HCE para distintos ámbitos, con distintas necesidades de registro.
Se probará la capacidad de adaptación del framework a situaciones reales, para evaluar y mejorar la adaptabilidad.
Se agregarán funcionalidades particulares e integración con otros estándares mediante "plugins".