Salvando vidas gracias al software libre

Todo buen trabajo de software comienza a partir de las necesidades personales del programador. (Todo buen trabajo empieza cuando uno tiene que rascarse su propia comezón). Eric S Raymond.

Se habla mucho ultimamente del nuevo programa informático que nos han implantado por la cara en Madrid. Es un programa lleno de errores de implementación de bulto. Errores que retrasan la consulta, quitan tiempo al médico para poder dedicarlo a lo importante (que es el paciente y no el ordenador) y lo peor de todo: pueden producir muertes.

El problema de un sistema informático es que en general pretende que la realidad se adapte a la estructura de datos del sistema y no al revés. Y luego pasa lo que pasa.

Uno de los errores más graves es que el sistema te obliga a la hora de emitir una receta a poner la dosis en un formato completamente rígido: "desayuno, comida, cena, al acostarse".

Sorprende que el analista informático no haya caido en que hay medicamentos que no se toman "en el desayuno", sino a lo mejor cada 3 horas. O medicamentos que no se toman todos los días igual, o que se toman una vez a la semana, etc, etc, etc.

En el software anterior (OMI-AP) el programa te daba la opción de poner una posología tipo "desayuno-comida-cena-al acostarse", pero era opcional (podías dejarlo en blanco y el sistema seguía emitiendo las recetas sin problemas). Aquella posología se utilizaba para emitir unas hojas de tratamiento para los pacientes analfabetos con unos dibujitos de "desayuno, comida, cena" muy útiles... siempre que fuese algo optativo.

En la nueva versión el sistema te obliga a meter una dosificación en ese formato. Si lo dejas en blanco como no te imprime la receta y si pones un cero tampoco. Te obliga a que el paciente se tome al menos una pastilla al día, en el desayuno, la comida, la cena o antes de acostarse.

Esto ocurre porque la empresa que ha desarrollado el software no ha hecho los deberes, y en realidad no ha habido analista informático alguno (nadie se ha reunido con los profesìonales). Simplemente se ha cogido el programa anterior, se han copiado los formularios y se ha reprogramado todo en un entorno web con base de datos centralizada... y de paso "arreglamos esos errores del programa anterior como que dejen emitir recetas con las dosis en blanco, que eso no puede ser lógico" (pensaría el programador de turno).

El problema es que ese "error informático" puede costar vidas. Por ejemplo en el caso del sintrom, medicamento que se usa para diluir la sangre. Las dosis de sintrom deben ajustarse a cada paciente y son variables según el día. A lo mejor el lunes y martes tienes que tomar tres cuartos, y el miercoles y jueves una pastilla entera.

Para emitir la receta sin embargo tienes que poner una dosis fija. Imaginemos que es un paciente anciano itinerante de esos que cada mes les cuida una persona distinta. O la cuidadora habitual cambia y llega una nueva. Como no está segura de qué dosis hay que darle al anciano decide mirar la receta y ve que pone "una en la cena"... así que siguiendo las instrucciones del médico le da una pastilla todos los días. Al poco tiempo el anciano aparece muerto con una hemorragia interna.

Es una probabilidad remota, pero es una probabilidad. Y las casualidades ocurren, sobre todo cuando se trata de errores informáticos en el campo de la medicina.

Si el programa AP-Madrid fuera de código abierto (como linux) cualquier médico con un poco de conocimientos de programación, se daría cuenta del error y podría subsanarlo rápidamente, sin tener que esperar a que el equipo de ingenieros se reuniese y pusiese ese error como prioridad (se ha notificado a los responsables desde hace semanas y sigue sin arreglarse).

AP-Madrid no es software libre (no vamos a pedirle a nuestros políticos que sepan ni siquiera de qué va el asunto), pero están tan cutremente programado que uno puede acceder a las funciones javascript viendo el código fuente de la página (son tan cutres que ni siquiera utilizan el siempre elegante

script type="text/javascript" src="external.js">

).

Pues bien, aquí está la función javascript que puede provocar muertes (los comentarios son los del propio programador, la negrita es mía...):

function calcularDosis() {

var p1 = document.getElementById('prescripcion.posologiaToma1Txt').value;
var p2 = document.getElementById('prescripcion.posologiaToma2Txt').value;
var p3 = document.getElementById('prescripcion.posologiaToma3Txt').value;
var p4 = document.getElementById('prescripcion.posologiaToma4Txt').value;

//Los decimales los acepta con tipo float, pero las fracciones hay
que tratarlas
if (p1.indexOf("/") != -1) p1 = fraccionAFloat(p1);
if (p2.indexOf("/") != -1) p2 = fraccionAFloat(p2);
if (p3.indexOf("/") != -1) p3 = fraccionAFloat(p3);
if (p4.indexOf("/") != -1) p4 = fraccionAFloat(p4);

//Eliminamos los posibles espacios en blanco
p1 = p1.replace(" ","");
p2 = p2.replace(" ","");
p3 = p3.replace(" ","");
p4 = p4.replace(" ","");

//Si son vacios lo sustituimos por cero
if (p1 == "") p1 = "0";
if (p2 == "") p2 = "0";
if (p3 == "") p3 = "0";
if (p4 == "") p4 = "0";

var posologia = parseFloat(p1)+parseFloat(p2)+parseFloat(p3)+parseFloat(p4);
var horas = 24;

if ((document.getElementById('nomenclator.idNomenclator').value!=null) &&
('C'=='D') &&
(posologia!=0.0) && (horas!=0.0)) {

dosis = document.getElementById('prescripcion.dosis');
intervalo = document.getElementById('prescripcion.intervalo');
An = posologia * 24;
Ad = horas;
reducir();
dosis.value = An;
intervalo.value = Ad;
}
}

Pues bien, para arreglar el problema y evitar muertes bastaría con eliminar lo resaltado en negrita (y quizá tocar alguna parte del código donde pueda darse una division by zero).

No es difícil, se hace en 10 minutos; siempre por supuesto que arreglar ese problema esté en tu lista de tareas prioritarias.

¿A qué esperan los de la consejería?... más mascadito no se lo puedo dar.