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... ;-)
