Una vuelta de tuerca sobre los costos de Health IT.

Para cualquier gestor el control de los costos es una necesidad perentoria, y mucho más en situaciones económicas adversas como la que actualmente atravesamos.

Así es, pues, como siempre se intenta aquilatar el proceso de adquisición de cualquier tipo de bien, y como no podía ser de otra manera, esto afecta a la IT.

Por otro lado, bien pudiera preocupar a este gestor el rendimiento de la inversión en IT, y fuera de los ya conocidos cuadros de amortización, o del ROI (Return of Inversion) poco más podemos ofrecer como métrica.

Pero, siendo atrevidos, quizás podemos crear una métrica nueva y diferente para medir el rendimiento de Health IT... y ya sabemos, Peter Drucker dixit, "todo lo que se puede medir, se puede mejorar".

Así que vamos a poner manos a la obra...

Introduciré una métrica nueva: coste por transacción.

Me parece ver como enarcáis las cejas...

Bien, de entrada, para definir este coste necesitamos identificar todos los costes asociados a la operación IT, es decir:

  • Coste salarial
  • Rentings
  • Inversión
  • Amortizaciones
  • Mantenimientos
  • Comunicaciones
  • etc.

La suma de todo ello, en el periodo que usemos para la medida, nos va a dar el dividendo de la división... pero, ¿y el divisor?

Para encontrar la definición de transacción en el ámbito de HealthIT, quizás debamos acudir a una definición lo suficientemente ambigua como para que cubra cualquier línea de servicio, cualquier tarea departamental que pueda realizarse en cualquier centro sanitario.

Dado que estamos inventando, podríamos decir que una transacción es una asistencia, un contacto, entendido desde que el paciente entra por la puerta de nuestro centro hasta que sale por el mismo... y la definición sería válida para equipos de tipo ambulatorio tales como AP o AE, pero nos dejamos las hospitalizaciones.

Ahora bien, una asistencia clásica en hospitalización incluye todo el periodo en el que el paciente está hospitalizado, lo que implica que daríamos el mismo peso al contacto ambulatorio que al proceso de hospitalización, por tanto no vamos bien.

La mejor manera sería que en hospitalización usásemos las estancias, pero aún seguimos teniendo el problema de igualar la intensidad de contacto de la estancia de hospitalización con la del contacto ambulatorio.

Afortunadamente podemos usar la escala de ponderación de Rotterdam, que nos permite introducir un factor de corrección, un peso, que ayude a homogeneizar la información.

En esta escala definimos que:

  • Contacto ambulatorio pesa 1
  • Estancia hospital de día pesa 3
  • Estancia hospital pesa 5

Así pues es fácil... multiplicamos según los valores de la escala los datos de la memoria del periodo que queramos medir, y ya tenemos nuestro divisor... y si hacemos la operación tendremos nuestro flamante costo por transacción, nuestro nuevo KPI.

Bien, ahora nos falta un valor de referencia, así que os ofrezco uno...

Un grupo de hospitales, en total cerca de 700 camas, 250 de ellas en un hospital universitario, con 14 personas en el departamento IT, incluido CIO; todos sus servicios sanitarios sin papeles, basados en software estandard aunque están construyendo un nuevo software por sus propios medios... este grupo de hospitales en red dispone también de 6 áreas de AP, PACS / RIS y sistema de planificación de oncología radioterápica para su batería de aceleradores... el coste por transacción de este grupo ronda los 0,95€.

Este grupo de momento tiene un parque de unos 1000 PCs, pero están en el proceso de paso de MS Office a OpenOffice, y por otro lado, van a pasar a un modelo de virtualización de escritorios, con lo que a medio plazo bajará aún más el coste por transacción.

Digamos pues, que el objetivo del gestor con este indicador sería intentar reducir dentro del escandallo del coste de la atención sanitaria, el coste de la operación IT.

Seguro que se puede poner en cuestión la escala usada para ecualizar los diferentes tipos de atención sanitaria, pero pienso que si queremos comparar de una manera tangible nuestra eficiencia IT, este indicador es quizás mucho más significativo para un gestor...

Y si créeis que se puede mejorar, ¡adelante!

Espero propuestas... ;-)

3 comentarios:

  1. Tu modelo me parece válido si te quieres considerar un centro de costes.

    Si yo fuese gestor intentaría valorar cada unidad (departamento IT en este caso) como centro de beneficios.

    La pregunta en ese caso es: ¿qué beneficio dan las IT?... porque a lo mejor llegamos a la conclusión de que el departamento (o alguna de sus inversiones) sobra porque no aporta valor.

    ResponderEliminar
  2. @drbonis el caso es que las IT en la mayoría de los casos es centro de costes... y sí, totalmente de acuerdo contigo: las IT deben introducirse cuando aportan valor, cuando no lo aportan sólo añaden costo y ruido.

    El departamento como tal nunca va a sobrar, pero si es cierto que se debe ser exquisitamente cuidadoso en el qué y en el cómo, pues el buen uso y aporte de valor de las IT no tan sólo vienen dadas por la tecnología en si, sino que la implantación, la gestión del cambio...

    ResponderEliminar
  3. Hummm, creo que es muy común considerar que parte del valor que aporta un departamento de IT es la gestión del cambio o la innovación de los procesos.

    El paradigma es: el proceso de diseño del sistema de información permite analizar lis procesos y el proceso de implantación nos permitirá cambiar los métodos de trabajo erróneos.

    El problema de este paradima es que al final la organización este al sericio del software y no al revés. Si dejas la innovación en manos de un tecnólogo es muy probable que obtengas innovaciones orientadas a la tecnología en vez de innovaciones orientadas a los problemas. He trabajado como tecnólogo y como clínico... Lo cual me ha hecho muy consciente de ese peligro.

    El departamento de IT debería ser un centro de beneficios, bien sirviendo a clientes internos (clínicos, logística) o por que no a clientes externos (servicios de IT para otras organizaciones, explotación de datos...)

    ResponderEliminar