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.
10 de julio de 2011
Marco conceptual para proyectos de informatizacion en salud
Etiquetas:
documentacion clinica,
hce,
historia clinica electronica,
informatica medica,
informatizacion,
procesos,
procesos de atencion,
sistema nacional de salud,
sistemas de informacion en salud
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.
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.
Etiquetas:
informatica medica,
informatizacion,
procesos,
procesos de atencion,
relevamiento,
sistemas de informacion en salud
Ubicación:
Pocitos, Montevideo, Uruguay
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).
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).
Etiquetas:
ciap-2,
cie10,
datos patronimicos,
dicom,
estandares,
hl7,
http,
ihe,
openehr,
pdq,
pix,
snomed,
web services,
xml
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:
Contenido:
Trabajo inmediato:
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?
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.
- 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.
- 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.
- 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:
- http://www.slideshare.net/pablitox/proyecto-traumagen-cais-jaiio-2010
- http://www.slideshare.net/pablitox/open-ehrgen-un-framework-para-crea...
- http://www.slideshare.net/pablitox/historia-clnica-electrnica-de-trau...
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.
Etiquetas:
arquetipos,
cda,
dicom,
ehr,
estandares,
hce,
historia clinica electronica,
hl7,
ihe,
modelo de conocimiento,
openehr,
salud movil,
sistemas de informacion clinicos
Suscribirse a:
Entradas (Atom)
