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.