La informatización en el área clínica es un camino que muchas instituciones de salud 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 una opinión 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 los 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?

Tomado de: informaticamedica

Califique nuestro contenido
[Total: 2 Promedio: 4]
Compartir en:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *