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.'
Fuente: La pella de gofio del Dr. Bonis 24/03/2010
Entradas
10 comentarios:
Aqui el Dr Bonis ha mezclado varias cosas, eso si presentando un interesantisimo caso de fallo o carencia grave de evidente resolucion sencilla que no llega
Si se estuviera en el caso de un software libre implantado como se debe en una organizacion seria el usuario (al que se le atendiera el derecho de hacerle llegar el codigo) con conocimientos no podria resolver el problema de la instalacion en produccion sino indicar como hacerlo ; naturalmente solo un grupo de personas con permisos adecuados -los administradores- deberian ser los capacitados de sustituir el programa fallido con el arreglado
Lo que aqui importa para el tema de si lo arreglan rapidamente no es que tenga que ser SW libre o no si no en que lugar estamos (y como) de la siguiente ordenacion simplificada
1. SW desarrollado a medida internamente
2. SW desarrollado a medida externamente pero quedando el cliente con la propiedad del SW
3. SW desarrollado a medida externamente con propiedad de la empresa externa pero con posibilidad de inspeccion de codigo
4. SW desarrollado a medida externamente con propiedad de la empresa externa y sin posibilidad de inspeccion de codigo por parte del cliente
5. SW producto externo
la situacion descrita en este caso tiene menos posibilidades de ser resualta rapidamente o puede tardar mas en general segun el orden creciente expuesto
Puede ser SW libre y estar en los casos 1,2,3 o 5 igualmente (eso si, en ese caso, en situacion probablemente mejor por ser libre)
De hecho en la situacion 1, seria para matar al desarrollo interno si no da una solucion inmediata, porque para eso se decide hacer desarrollos internos, para tener esa posibilidad de flexibilidad/capacidad de reaccion
A partir del 2 se empieza a estar "vendido", apenas en el caso del 1 si se puede traspasar el desarrollo a un dpto interno u otra empresa de forma agil en caso de falta de soporte de la actual
Lo bueno que tienen 1-3 es que con personal propio tecnico que inspeccione el codigo (como ha pasado en el caso por otras razones) el propio cliente puede localizar el fallo y lo que es mas no dejarse torear por excusas que se invente, interesadamente, la empresa
En los casos 4 y 5 se esta a expensas total de la capacidad tecnica y honestidad de la empresa, con lo que puede pasar de todo (desde respuestas rapidas muy buenas hasta, lo mas habitual, mentiras en las causas y no soluciones).
El pero de los casos seria un 5 si el producto es "importante" (digamos MS Word) y tu un cliente pequeño no tienes ninguna opcion de que te arreglen nada.
El SW vital de una gran organizacion seria deberia ser siempre con propiedad de la organizacion o un producto maduro de una version madura y soporte contrastado (y mejor si es libre, pero siendo mas esencial que sea maduro). Al menos asi se exige hacer en mi organizacion bancaria.
¿En qué caso está el programa que se menciona en la entrada ha sido implantado por la cara?
Pues te contesto.
AP-Madrid es el nombre que se le ha dado al en principio producto "OMI-AP Web Edition" desarrollado por la empresa STACKS-CEGEDIM, que no estaba maduro cuando se contrato, mas bien no existia en version web centralizada, con lo que de facto se ha convertido en un desarrollo para la ocasion (la propiedad del SW se la queda la empresa que lo vende como un producto)
En tu escala estariamos en el 5 pero que dada la situacion e importancia del cliente para el futuro del producto de la empresa podria considerarse el caso 4
Lo que no se es si el problema expuesto lo consideraran un fallo o una carencia de una version aceptada por el cliente cuya "resolucion" deberia ser un cambio (que pagar)
En este caso hay posibilidad de inspeccion parcial de codigo, la del Javascript en el cliente.
Soy de especializada y no tengo acceso al AP-Madrid, pero Dr. Bonis ya que te veo con ganas hay cosas que puedes probar.
Como sabrás, el servidor no puede controlar la parte cliente, sólo cómo responde ante las peticiones HTTP que le lleguen normalmente las construidas por el navegador tras la ejecución del Javascript de la página actual más la interacción del usuario.
Por supuesto, ese Javascript que se ejecuta en el cliente (navegador) se puede modificar antes de enviar la siguiente peticion.
Hay varias extensiones de Firefox que te pueden ayudar a hacer eso, creo. Por ejemplo, Firebug. Imagino que tb para Internet Explorer. Otras para Firefox que puedes mirar son JavaScript Shell Bookmarklet ,
Platypus y por supuesto la famosa
Greasemonkey, auténtica navaja suiza que te encantará.
Con una de esas extensiones (u otras similares si las hay para IE que desconozco pues no profeso esa religión) modifica la función que comentas a tu gusto en tu navegador, y prueba a dar a enviar. Así podrás comprobar si el cambio que propones tiene efectos colaterales en la parte de código tras el servidor que tú no puedes ves.
Así habrías encontrado una solución para imprimir tus recetas. Pero claro, cada vez entrar en el menú de la extensión y modificar la función es un rollo. Hay que automatizar esto con una macro cosa que quizás puedas hacer con esas mismas extensiones y más probablemente con Chickenfoot
o CoScripter
Son indicaciones o ideas, te lo tendrás que cocinar tú mismo ;)
Por cierto que lo que comentas del include del .js efectivamente es mas elegante y aporta algo de ofuscación pero no aporta ninguna seguridad real ante gente con mínimos conocimientos técnicos (si el navegador puede leer el .js para cargar las funciones tú también puedes hacerlo) o armado de extensiones :)
Me parece que se confunden conceptos al hablar de código abierto. Las ventajas del código abierto se establecen en la no dependencia del proveedor y la adaptación del software a las necesidades de tu negocio o empresa. Pero lo que aquí se defiende de manera absurda es que el propio usuario de la aplicación pueda cambiar el código para arreglar un problema (en este caso grave) y a partir de ahí dejarlo resuelto. Eso aquí no es así.
El código abierto no es un concepto de interacción del usuario con el desarrollo de la aplicación sino del desarrollo de la aplicación con la redistribución de la misma haciéndola llegar al usuario. No sé que extraña capacidad tienen algunos médicos o profesionales sanitarios de convertirse puntualmente en informáticos salvadores de la Tierra simplemente por conocer la sintaxis de algún lenguaje de programación. Grave error. Y ha quedado claro. Lo que hay en los profesionales sanitarios, sufridores injustamente de una aplicación evidentemente perfectible, es un gran desconocimiento de la capa del negocio y cierta incapacidad de sonrojo al intentar situarse en el ámbito del desarrollo de la aplicación. Se corre el riesgo de hacer el ridículo, como es el caso.
Dicho esto que quede claro que AP Madrid es un fracaso en la elección del mejor diseño tecnológico adaptado a las necesidades funcionales. Es una aplicación que nace antigua, que arrastra desde el primer momento gravísimos fallos de concepto y de diseño y que evidentemente genera extremadas dependencias en la adaptación y en las comunicaciones. En resumen un cierto fracaso inicial pero esperemos que resoluble.
Muy deacuerdo con el último comentario, Dr. Bonis eres a la Informática, lo que los espectadores de House somos a la Medicina.
Pues yo no estoy de acuerdo del todo con lo que dicen el penultimo acerca del codigo abierto
Desde luego es absurdo en una organizacion permitir que el propio usuario pueda cambiar el programa corporativo cuando se le antoje, esto es asi tanto si es software libre como si no lo es
Ahora bien en general la ventaja del codigo abierto o software libre no reside solo en "la no dependencia del proveedor y la adaptación del software a las necesidades de tu negocio o empresa" (ambas cosas muy importantes) sino precisamente tambien en la posibilidad de participación de un usuario con conocimiento técnico en la localización y sugerencia de arreglo de errores o incluso arreglo
Cuánto de ventaja es esto ultimo depende del ámbito y uso del software. En el caso de usuario particular de un programa en su casa, mucho mejor si tiene la posibilidad de arreglarlo él mismo ¿no?. Y si el remedio es peor que la enfermedad pues él se come las consecuencias. Si no lo consigue siempre puede seguir usando la version mala.
En el caso de una organización repito que es absurdo lo de permitir que lo arregle el usuario. Ahora bien, ¿qué tiene de malo aceptar la posibilidad de recibir sugerencias que luego el dpto de desarrollo pueda o no tener en cuenta como base para un cambio controlado?
Algunos cambios o arreglos importantes de código en la rama de desarrollo "oficial" de proyectos de software libre públicos han venido sugeridos por usuarios (avanzados o con algún conocimiento de programación) del programa que no eran miembros del equipo de desarrollo "oficial". Por supuesto esas sugerencias deben hacerse siempre desde un cierto grado de modestia y en el caso de una organización fuera del tiempo de trabajo para el que realmente le pagan ;)
Hay campos, generalmente científicos, que cuentan a veces entre sus miembros gente que pilota acerca de algunas tecnologías de programación (piénsese en el caso de la física de partículas o de las simulación de neuronas) y la contribución de código de los usuarios es mayor que la del equipo oficial de desarrollo. De hecho, muchos programas de esos campos han sido creados directamente por comunidades de usuarios (es decir de la gente que va a usar el progama cuya funcionalidad necesita).
El caso de la medicina ciertamente parece que se queda atrás aunque no conozco bien si realmente ya hay comunidades de médicos usuarios contribuyendo a proyectos de SW libre médico público.
Pero bueno eso es ya otra historia ...
> No sé que extraña capacidad tienen algunos médicos o profesionales sanitarios de convertirse puntualmente en informáticos salvadores de la Tierra simplemente por conocer la sintaxis de algún lenguaje de programación. Grave error.
Grave error hablar sin conocer. Existen médicos que también son informáticos.
> es un gran desconocimiento de la capa del negocio y cierta incapacidad de sonrojo al intentar situarse en el ámbito del desarrollo de la aplicación.
Lo que hay en este caso en concreto es una falta absoluta de respeto por las normas elementales en la ingeniería de software en el ámbito sanitario que exigen la participación de los profesionales sanitarios en el análisis de requisitos, la revisión del código por un auditor externo (en especial en funcionalidades críticas como la prescripción de fármacos), etc, etc, etc...
En el desarrollo de AP-Madrid no parece que hayan participado clínicos (y no valen licenciados en medicina con cargos de gestión, me refiero a clínicos de base, de los que usan la herramienta).
El error en el módulo de prescripción es tal que cualquier clínico que hubiese usado la herramienta un par de veces para emitir una receta en condiciones simuladas (ni siquiera hablo de situación real en instalación piloto) se habría dado cuenta del error.
El error de diseño existía en la versión anterior (OMI-AP) pero el sistema permitía un valor null (imagino que una excepción añadida posteriormente a pelo tras la notificación del bug por algún clínico, pero no presente en los documentos de análisis iniciales) y por tanto permitía al usuario encontrar un atajo al universo contemplado por la estructura de datos de la aplicación.
AP-Madrid se ha desarrollado simplemente trasladando el código a una nueva plataforma, con tan mala suerte que los errores de diseño originales están empezando a saltar, gracias al excesivo celo del programador de turno.
No es comprensible que ese error de diseño termine en un entorno de producción real como es el caso.
O sí lo es, considerando que probablemente los encargados de todo esto jamás habrán leido sobre el Therac-25 ni otros clásicos de la informática médica.
Y encima serán capaces de darse palmaditas en la espalda con la superherramienta rollo SAP que han construido.
>El caso de la medicina ciertamente parece que se queda atrás aunque no conozco bien si realmente ya hay comunidades de médicos usuarios contribuyendo a proyectos de SW libre médico público.
MedCalc es una de las aplicaciones (en realidad un conjunto de aplicaciones) más utilizadas en la práctica real por clínicos (las primeras versiones como simple plantilla excel, y ahora en iPhone). Fue desarrollada inicialmente por un médico clínico.
> en el caso de una organización fuera del tiempo de trabajo para el que realmente le pagan ;)
Si me dan una herramienta de trabajo defectuosa me veo en la necesidad de intentar ver por qué no funciona. Desde luego no pienso dedicarle horas extra fuera de mi jornada laboral a solucionar problemas que yo no he generado.
Publicar un comentario