El camino hacia la modernización de la HIT pasa por la racionalización de las aplicaciones
Kaitlin Traft ha visto cómo se desarrollaba la conversación sobre la modernización desde ambos lados: las organizaciones que la persiguen y las que hacen primero el trabajo más duro de racionalización. Su argumento es sencillo, y va en contra de muchas de las ideas actuales. No puedes modernizar lo que no has racionalizado. He aquí por qué importa ese orden.
Ahora mismo se está produciendo una conversación en el ámbito de las TI sanitarias, y creo que estamos utilizando la palabra equivocada.
Modernización y racionalización no son lo mismo. Sanidad sigue utilizando ”modernización” cuando la verdadera palabra (la verdadera necesidad) es racionalización. Modernizar es mejorar la tecnología existente. Racionalizar es decidir qué se mantiene y qué se elimina.
Y esa distinción importa más de lo que la mayoría de la gente cree.
No modernizas 400 aplicaciones. Miras las 400 y decides: a lo mejor 300 se quedan, pero 100 se van. Porque a veces hay duplicidad en esas aplicaciones. Racionalizas para desmantelar, para deshacerte de cosas que ya no necesitas y luego modernizas lo que queda.
Piénsalo en la forma más pequeña. Estás modernizando tu HCE para introducir herramientas de IA. Pero no necesitas necesariamente esas otras herramientas de IA que tienes en funcionamiento secundario, porque estás modernizando la propia HCE. Te estás deshaciendo de herramientas que no necesitas para hacer lo que realmente quieres hacer. El objetivo puede ser la modernización, pero primero tienes que mirar lo que hay bajo el capó.
Esa secuencia (racionalizar, luego modernizar) es donde muchas organizaciones se atascan.
La gente piensa, vale, queremos modernizarnos. Pero no siempre piensan en lo que ocurre antes de la modernización. Y los que avanzan más rápido ahora mismo no se limitan a implantar nueva tecnología. Están simplificando agresivamente el entorno subyacente para poder avanzar agresivamente con la IA, o Epic, o cualquiera que sea la próxima iniciativa. Están haciendo ambas cosas y entienden el orden.
Se trata de un problema de mano de obra, no sólo de tecnología
Aquí hay algo que no creo que se diga lo suficiente: la racionalización de las aplicaciones es una estrategia de personal.
Los equipos informáticos de la sanidad suelen estar quemados y es porque gestionan o dan soporte a demasiados sistemas. No puedes resolver ese tipo de agotamiento pidiendo a la gente que mantenga 15 años de deuda técnica que la organización ha absorbido con el tiempo y que ya no puede explicar. Con el tiempo, las razones se hacen más difíciles de rastrear. Los sistemas se absorben, los contratos se renuevan con el piloto automático, y el panorama completo se vuelve difícil de ver desde dentro.
Y esa es la cuestión: para hacer realmente una racionalización de las aplicaciones, primero tienes que alinear a las personas de toda la organización. Tienes que reunir a todo el mundo en la sala y decir, vale, esto no está funcionando. ¿Dónde podemos centrarnos? ¿Qué aspecto tiene realmente nuestra pila tecnológica completa? Sólo entonces podrás examinar las aplicaciones y empezar a tomar decisiones reales.
Ese proceso comienza con un inventario, y me refiero a un inventario real. Sí, hay una hoja de cálculo. Pero lo más importante es que te sientes con las partes interesadas de toda la organización: equipos de aplicaciones empresariales, RRHH, dirección clínica, cualquiera que tenga supervisión sobre lo que utiliza su departamento y por qué. Los estás entrevistando. Les preguntas qué usan, cómo lo usan y qué pasaría si desapareciera. Ahí es donde encuentras la duplicidad. Piensa en algo sencillo, como una aplicación de AI para escribanos. Un equipo utiliza Abridge, otro Nuance. Funcionalmente, hacen lo mismo. Entonces, ¿cuál es mejor? ¿Cuánto cuesta? ¿Cuándo caduca la licencia? Lo estudias todo y luego se convierte en:¿cuáles retiramos y por qué?
El coste real nunca es sólo la licencia
Una cosa que oigo constantemente es que las organizaciones utilizan el coste de las licencias como principal lente para las decisiones de jubilación. Y lo entiendo; es la cifra que aparece en la factura. Pero el coste de las licencias es casi siempre la parte más pequeña del problema.
El coste real es la infraestructura sobre la que se asienta la licencia. Son las interfaces, las actualizaciones, los analistas, los tickets de soporte, los gastos generales de gobierno, el riesgo de inactividad. Hay muchas capas más allá de esa partida de una línea. Y la mayoría de las organizaciones lo subestiman enormemente.
Hay algunas otras preguntas en las que pienso cuando trabajamos en la priorización de la jubilación. ¿Lo hace ya tu HCE? Si eres una organización que da prioridad a la HCE, ése suele ser el primer filtro. Si tu HCE puede replicar el flujo de trabajo, entonces centralizas los datos y los introduces. La pregunta deja de ser ”¿debemos mantener esta aplicación?” y empieza a ser ”¿por qué pagamos por algo que nuestra HCE ya puede hacer?”.
Luego está la parte del flujo de trabajo clínico. Si un médico tiene que salir de la HCE, iniciar sesión en otra cosa, hacer una cosa y volver… eso es una desconexión. Eso es fricción a pie de cama. Una enfermera que atiende a 15 pacientes no tiene tiempo de entrar y salir de los sistemas para conseguir lo que necesita. ¿La aplicación simplifica su flujo de trabajo o lo interrumpe? Esa respuesta importa.
Y luego está la cuestión del futuro: ¿está esta aplicación acelerando la adopción de la IA, o la está bloqueando? Porque si los datos están aislados, si los resultados son incoherentes, si la aplicación no puede conectar con el rumbo de la organización, no merece la pena mantenerla. Deshazte de ella.
La pregunta que siempre me hago
La pregunta más importante en cualquier conversación sobre racionalización no es: ”¿deberíamos quedarnos con esto?”. Es: ¿qué pasa si no lo retiramos?
Porque no hacer nada es lo más caro. Si no te fijas, podrías tener una aplicación funcionando durante años (es decir, seguir pagando por ella, seguir dotándola de personal, seguir gestionándola) y nadie sabe exactamente qué está haciendo o si alguna vez mereció la pena. Eso es deuda técnica acumulándose silenciosamente. Eso es carga operativa que nadie presupuestó. Eso son flujos de trabajo fragmentados que nadie diseñó.
La racionalización de las aplicaciones ya no es una iniciativa de limpieza informática. Es un requisito previo para la eficiencia operativa, para la preparación para la IA, para cualquier estrategia de HCE a largo plazo que estés intentando ejecutar. Las organizaciones que lo hacen bien no lo tratan como un proyecto secundario. Lo tratan como la base.
No puedes construir sobre una cartera hinchada. Tienes que saber lo que tienes antes de decidir en qué te vas a convertir.
Share this