¿Por qué cuestan tanto los proyectos de interoperabilidad?

Todos los que vivimos el día a día de las integraciones, sea desde el lado de la mesa que sea, somos conscientes de que los proyectos son costosos, no tanto desde un punto de vista económico como en el plano operativo. Desde el comienzo hasta que por fin se llevan al entorno real suelen pasar meses (o incluso años en algunos casos) y sufren mil y una contingencias.

Sin buscar culpables (porque todos somos un poco responsables) revisamos algunas de las causas que conducen a esta situación.

Al principio, el interés es máximo
La gran mayoría de proyectos de integración comienzan siempre generando importantes expectativas. El objetivo de automatizar los flujos de información y las ventajas que esto puede acarrear suelen suponer una ayuda al trabajo de los profesionales y por lo tanto se esperan casi siempre con gran interés.

A pesar de ello hay dos cosas que suelen dejarse de lado: las necesidades que tendrá la integración en sí misma y las implicaciones sobre los procesos asistenciales involucrados. Esta falta de información genera que los proyectos, finalmente, no sean en muchas ocasiones lo que se espera y no alcancen esas expectativas esperadas.

Pero el desarrollo (casi) siempre es más lento de lo esperado
Sin embargo, una vez que el trabajo comienza, se desarrolla siempre (casi sin excepción) más lentamente de lo esperado. Y esto genera un importante desencanto en los usuarios, que no ven culminar las expectativas despertadas.

Si intentamos determinar los motivos de esta aparente lentitud en los proyectos de interoperabilidad podremos encontrar mil y uno diferentes. Cada caso es particular y especial pero si los analizamos todos veremos que hay una serie de ellos que son comunes a casi todos:

Nula visión de lo que significa interoperar: ya hemos hablado del significado del término y de lo que suponen este tipo de proyectos pero parece que aún no nos hemos dado cuenta de que interoperar no es sólo mandar mensajes. No se abordan los proyectos desde un punto de vista completo (incluyendo los procesos funcionales) lo que deriva en inconsistencias, errores de definición, problemas funcionales…
Falta de análisis y de gestión conjunta: por esta falta de conciencia de que la integración no es únicamente un problema técnico, los proyectos de integración suelen verse como el trabajo de dos partes, una frente a la otra, sin que haya nada ni nadie en el medio coordinando los esfuerzos. Nada más lejos de la realidad y cuando finalmente el proyecto se lleva a cabo es cuando surgen todos los problemas funcionales que quedaron sin analizar. Y sin alguien que ordene y gestione estas diferencias surgen los conflictos que retrasan los proyectos.
Cada uno por su lado: de la mano del punto anterior, cada proveedor trabaja por su cuenta y sólo al principio (en la definición) y al final (en las pruebas) se juntan. No hay una voluntad real de trabajo conjunto sino de desarrollar el trabajo en base a unas especificaciones cerradas que no sufran ninguna alteración a lo largo del proyecto (lo que nunca sucede). De esta forma y llegados a las pruebas suelen surgir los problemas en las estructuras, los datos, los procesos, etc.
Nadie da su brazo a torcer: en este escenario de especificaciones sin cambios, cada proveedor dispone por lo general de especificaciones cerradas que no quiere cambiar para adaptarse al resto del mundo. Enfrentando especificaciones disponibles cada uno de ellos trata de hacer los menores cambios posibles en sus sistemas y por lo tanto los desencuentros suelen estar a la orden del día. Sin nadie que ponga paz, la negociación necesaria dilata los plazos de ejecución.
Poca participación del usuario y (casi) nula formación: y aunque todo se diseñe y desarrolle sin problemas, llegará el momento en que los usuarios se enfrenten al resultado. Y no será raro el proyecto en que éste no cumpla con las necesidades que los profesionales tenían. Evidentemente esto es una consecuencia de los puntos anteriores ya que, al verse como proyectos meramente técnicos, no se hace partícipe al usuario de qué y cómo se hará y el resultado puede ser insuficiente para sus necesidades.

En el fondo poco importan los motivos y quién es el responsable en cada caso. El hecho es que los proyectos de integración suelen ser lentos, suelen sufrir muchos retrasos y no cumplir las expectativas generadas. Y todos, sin excepción, somos un poco culpables de que esto sea así.

La receta electrónica y la historia clínica electrónica como ejemplos
Alguno de los mejores ejemplos de lo lentos que van los proyectos de interoperabilidad los podemos buscar a nivel estatal en los proyectos de historia clínica electrónica y de receta electrónica.

A pesar de que la receta electrónica está ampliamente implantada a nivel autonómico, aún no se ha conseguido que un ciudadano pueda viajar de una comunidad a otra con sus recetas. El proyecto de interconexión entre comunidades, que dio comienzo en el año 2015 (y tenía previsto finalizar en 2016), aún no ha conseguido interconectar más que a 5 de ellas, permaneciendo el resto aisladas entre sí.

El proyecto de historia clínica compartida no va mucho mejor. A pesar de que lleva encima de la mesa varios años aún queda mucho trabajo por hacer para tener una historia clínica unificada en el SNS. Por no hablar de la interconexión entre países de la Unión Europea (el famoso proyecto Epsos), que se propuso en 2008 y está como está.

Ambos son claros ejemplos de que aunque los proyectos se inician con grandes expectativas el desarrollo es siempre más lento de lo previsto y de lo deseado.

¿Se pueden solucionar estos problemas?
Evidentemente y como profesionales que somos la respuesta debe ser SÍ y es más, debemos abordarlos lo antes posible para poner solución a una situación que es, a todas luces, preocupante.

En este escenario deberá ser fundamental el trabajo de concienciación hacia ellos y la colaboración conjunta entre todos los implicados, más allá de las diferencias y de los intereses propios. Sólo así proyectos de esta complejidad podrán finalizar con éxito.

Los proyectos de integración siempre tienen un componente especial que los hace algo más complicados que el resto de proyectos. Sin embargo y entre todos debemos hacer, dada la importancia que hoy en día tiene la interconexión de sistemas, que los proyectos salgan adelante y podamos hacer una sanidad más y mejor conectada, más completa y más útil para pacientes y profesionales.
..Pedro Gonzalo. Hablando de eSalud

Opinión

Multimedia

Economía

Accede a iSanidad

Síguenos en