Katty estaba feliz, veía crecer a su pequeña hija y su matrimonio parecía florecer cada día más. Nada podría hacer dudar sobre el futuro de su vida hasta aquella noche en la que descubrió una dureza en su mama derecha, luego de una reparadora ducha. Su cara cambió de repente y John se dio cuenta al instante. El mismo fue el que la intentó animar diciéndole que seguramente no sea lo mismo que lo que le había sucedía a su abuela. «Seguro es algo temporal, mañana iremos a ver al médico para estar seguros«.
No fueron tan alentadoras las palabras de William al día siguiente, el médico de la familia enseguida la derivó a un experto en la materia para que le haga estudios. Cáncer de Mama era el diagnóstico y días después ya había sido intervenida. «Menos mal que lo agarramos a tiempo» argumentó el experto, el tumor era muy pequeño y no hubo metástasis. «Luego de un par de sesiones del nuevo tratamiento con rayos podrás olvidarte de esto y seguir con tu vida» terminó diciendo, muy confiado.
A la semana Katty se presentó en el hospital de Ontario a recibir su primera sesión de rayos. Ella fue recibida muy amablemente y a los pocos minutos ya estaba acostada dentro de la camilla de la Therac 25, una máquina que según decían sus operadores «estaba haciendo maravillas». Ella vio como el aparato comenzó a hacer una especie de vibración y se paró repentinamente, y vio una extraña cara de ansiedad en el operario. Luego de 10 segundos comenzó a vibrar nuevamente y como ella era nueva creyó que el ardor y la extraña sensación de descarga eléctrica eran normales. Katty siguió recibiendo rayos durante un tiempo hasta que su estado se volvió cada vez peor y a los pocos meses recibió la noticia de que extrañamente tenía un Cáncer fulminante en el pulmón derecho, justo a la misma altura donde recibía los rayos.
Katty murió a las pocas semanas y fue uno de los tantas víctimas del «bug de la Therac-25« y según dicen luego de este caso fue necesaria la elevación de los estándares de testeo y revisión de código en sistemas médicos.
El problema – gracias Wikipedia – «sucedía cuando el haz de electrones de alta potencia era activado en lugar del haz de baja potencia, sin la placa difusora colocada en su sitio. El programa de la máquina detectaba un error, pero no prevenía que el paciente recibiera la dosis de radiación, algo potencialmente letal. La radiación beta que el usuario recibía era aproximadamente cien veces mayor que la dosis esperada de radiación. Un paciente, Raymond Cox, describe una sensación similar a «una intensa descarga eléctrica», lo que provocó que gritara y huyera de la sala de radioterapia. Varios días después de la exposición los pacientes empezaron a mostrar graves quemaduras. En tres casos, los afectados fallecieron por envenenamiento por radiación.
Se determinó que el mal funcionamiento del programa era ocasionado por una condición de carrera, relacionada con el desbordamiento de una variable contadora. Cuando el técnico suministraba ciertas instrucciones en el momento en el que ocurría el desbordamiento del contador, los mecanismos de seguridad no se ejecutaban.«
Es muy interesante, además, conocer el extenso flujo de errores e imprudencias que llevaron al equipo a generar la muerte de varios pacientes. Desde no contar con un una auditoría de código externa pasando por la falta de documentación (el sistema mostraba el mensaje Malfunction junto con un número pero en los manuales no existía documentación al respecto) hasta el colmo de que los operarios pasaban por alto las quejas de los pacientes. El final no podía ser de otra manera.
Esto sucedió hace más de 20 años y si bien a la fecha los sistemas de radiación fueron perfeccionados y un error de estos ronda lo imposible todavía muchos programadores de software alegan frases como «nadie murió por un error en el código«. Seguramente ellos no conozcan la historia de la Therac 25.
Parece que mucho no se elevaron los estándares.
La gente se esta muriendo por unas tomografias hechas con un protocolo mal diseñado.
Capaz que alguien dejo un torx adentro!
Muy interesante el post, pero tambien muy corto, se acaba justo cuando le hace a uno agua la boca y no especifica nada sobre el error.
En la Wikipedia encontre informacion muy interesante que sirve de complemento perfecto: http://es.wikipedia.org/wiki/Therac-25
@klazerver, gracias por tu comentario, si te fijas el link a la Wikipedia ya estaba puesto
Saludos.
Definitivamente te pone a pensar que hay cosas en tecnología que das por hecho, el ejemplo es que en la medicina lo «ultimo» y lo que está haciendo maravillas se encuentra en fase beta.
Lo mismo pasó con los Curie.
Nunca confie en las cosas manejadas por computadora… tengo el presentimiento de que algun dia se «cuelgan» y hacen estas cosas…
Los autos cada vez mas automaticos me dan aun mas miedo…
Interesante la info. Saludos!
Pues los humanos cometen más errores. xD
Peor es que te construyan tu casa con materiales radiactivos: http://en.wikipedia.org/wiki/Kramatorsk_nuclear_poisoning_incident
[troll_mode=ON]
Seguro que usaba windows…
[troll_mode=OFF]
Y si, lo tenía que decir…
=P
«El programa estaba escrito en lenguaje ensamblador, un lenguaje de bajo nivel que requiere más trabajo de diseño, programación y pruebas. Además, se programó sobre un sistema operativo propio.»
Esto es lo que pasa cuando se comenta sin leer la fuente Será la próxima
Nachox, yo también estoy de acuerdo con tu comentario, yo francamente no le confiaría mi vida a un aparato que funcione bajo windows (si, súper paranoica, lo admito).
En la Semana de la Computación en la UBA (Universidad de Buenos Aires), me acuerdo que una vez hubo una charla en la que se habló de este tipo de errores.
¿A cuantas personas salvó «la máquina» antes de matar a una? Los errores informáticos no existen si se toman las medidas oportunas…
No es broma, hay máquinas médicas que llevan energía nuclear y pueden ser muy peligrosas.
En Zaragoza murieron varias personas por una avería en una máquina de radioterapia de GE.
Allí abajo dejo un link.
http://www.elpais.com/articulo/sociedad/INSTITUTO_NACIONAL_DE_LA_SALUD_/INSALUD/QUIMIOTERAPIA_/_RADIOTERAPIA/Tercera/muerte/radioterapia/Zaragoza/accidente/grave/mundo/Insalud/elpepisoc/19910222elpepisoc_13/Tes?print=1
A los de Windows, normalmente ese tipo de maquinas no funcionan bajo windows, (en el enlace de la wiki lo dice, utilizaba su propio sistema operativo y escrito en lenguaje ensamblador), se que es el chiste facil….
tambien hay que decir que en el articulo de la wiki dicen que no se testeo el software con el hardware antes de instalarlo, que los errores estaban numerados del 1 al 64 sin que aparecieran en el manual de usuario, y unos cuantos desastres mas…
El software como todo hay que probarlo y asegurarse que funcionan bien, tanto software como hardware. Y la culpa se la hecha al programador cuando seria la compañia la que meteria prisa por sacar un producto sin estar minimamente testeado.
Una triste historia, sin duda. Aunque no puedo dejar pasar por alto un pequeño detalle. La fotografía corresponde a un acelerador lineal Clinac 2100C de la empresa americana (VMS) y la historia que mencionas es sobre el acelerador lineal Therac25 de la compañía canadiense (AECL). Son compañías diferentes y sus aceleradores no poseen la misma tecnología.
No estaría mal actualizar la imagen por una donde se muestre el verdadero acelerador Therac25, o en su defecto, una imagen de un acelerador genérico e.j. http://www.extension.iastate.edu/foodsafety/images/uploaded/irradiation/smlaf.GIF
El error no fué de la máquina, sino de su programador. Y supongo que esta máquina (o familiares) salvarían muchas vidas.
Respecto al resto de cosas electrónicas (como los coches que se ha dicho por ahí), claro que también cometerán errores, pero mientras ellos se equivocan 1 de cada 100 veces (por ejemplo) nosotros nos equivocaremos 15 de cada 100 (por ejemplo).
El futuro es una sociedad tecnificada!
las maquinas no cometen errores, son perfectas en su imperfección, los errores los cometen los programadores, y en cierta forma los operadores/usuarios, la maquina simplemente sigue al pie de la letra las instrucciones que se le asignan…
Este error es la introducción de cualquier temario universitario de Ingeniería Informática… En la parte de auditoria informática y/o informática forense se dan estos casos de error.
Si fuera sólo este el que se ha cargado a gente.. nadie toma en cuenta que la informática puede matar gente, parece un acto de magia potagia que haya un error informático… Nadie considera la informática como una ingeinería, con sus «planos» análisis, diseños y pruebas exhaustivas.. planificaciones, gestión de recursos, análisis de viabilidad… son cosas que se van haciendo sobre la marcha xq lo importante es «que tire»..
podéis ver más errores fatales, algunos de vidas humanas otros de muchos millones de euros: http://www.regulacioninformatica.org/wiki/index.php/Portada en el apartado «Impacto Social»
NOTESE QUE ESTOS INCIDENTES NO SON RECIENTES, SINO QUE OCURRIERON ENTRE 1985 Y 1987. EN TOTAL FUERO 6 CASOS DE LOS CUALES 3 MURIERON.
Al autor del blog: esta nota asusta al pedo a la gente. Recibir el tratamiento por radiación es muy importante en un paciente oncologico. La gente se impresiona con estos temas y lo que escribiste da la sensación de que fuese reciente y quizás provoques que alguien tome una decisión errónea basado en el miedo que provoca lo que sugiere esta entrada.
Tenés razón Agustín.
Pero también tené en cuenta que no subestimo a la gente y en el artículo está bien explicado que esto pasó varias décadas atrás.
Un abrazo.
Cierto, yo no conocía este caso y alguna vez he entonado la famosa frase de que «nadie ha muerto por un programa mal hecho» o por unas líneas de código… Ahora sé que hay gente que puede morir por unas líneas de código mal hechas… al igual que hay gente que puede morir por unas líneas de código muy bien hechas utilizadas en el armamento militar. Pero también quiero señalar que siempre se ha justificado el sueldo de los médicos diciendo que las vidas de sus pacientes están en sus manos, sin embargo, los programadores cuyo trabajo influirá en la vida o la muerte de personas como el desafortunado caso que se describe en este post tienen contratos precarios fruto de subcontrataciones en las que el dinero que perciben es una miseria resultado de todo el dinero que se ha ido perdiendo por el camino entre las manos de los intermediarios.
En muchos de los casos se trata de programadores poco cualificados ya que son más baratos para las empresas que están más interesadas en hacer algo para salir del paso y cobrar el dinero. Es una situación bastante triste.
Muy interesante el caso. Aunque era un problema netamente de diseño, a veces pasan este tipo de problemas por esa costumbre que tenemos en sudamérica en general (y Argentina en particular) de no mantener la maquinaria compleja según su programa de mantenimiento, o de poner en práctica las regulaciones que impone la ley (si es que la hay).
Me acuerdo de un caso conocidísimo en Brasil, a finales de los 80 si no mal recuerdo. Había un equipo de tratamientos por radiación en un hospital, que contenía una barra de Cobalto 60 para administrarla. El hospital cerró, fue abandonado, y a nadie se le ocurrió retirar la barra de material radiactivo del lugar (en teoría debía existir una ley que regule el destino de los materiales radioactivos y un organismo que se encargue de que se cumpla, no se si era el caso en Brasil en ese momento).
Gente de bajos recursos y poca educación, entró en el edificio, vió esa barra de material brillante (por el efecto de Cherenkov, supongo que al pasar por la ventana del cartucho metálico que lo contiene), y se la llevó. El tipo era herrero o algo similar, y le hizo un colgante a su mujer con ese metal raro. Varias semanas después la gente alrededor de ellos empezó a enfermarse, hasta que la mujer llevó el colgante al hospital y se dieron cuenta del problema. La mujer murió, y creo que hubo unas 15 o 20 personas más afectadas por las limaduras de metal que quedaron en la zona.
A partir de ese incidente se empezó a hacer un seguimiento mucho más riguroso de dónde se encuentran fuentes de radiacion no naturales a nivel mundial.
Comentario aparte: AECL es el fabricante de los reactores CANDU, de los cuales hay uno en Argentina, en la central de Embalse Rio Tercero, Córdoba. Los tipos tenían un diseño de reactor refrigerado por aceite mineral muy interesante (el aceite tiene mayor capacidad térmica que el agua, por lo que circulaba a menor presión y ahorraba todos los sistemas de alta presión que tantos problemas tienen por el alto desgaste). Lástima que después de Chernobyl y Three Mile Island, desarmaron todo.
ke clase de frase es esa: “nadie murió por un error en el código“, no creo que ningun profesional piense asi, si en carreras de ingenieria es recurrente que tus profesores te recuerden que un error puede costar vidas.
uf, si que da un poco de miedo, que lo sumamos a tener cancer… no quiero ni pensarlo.
Vaya puta mierda de articulo. Parece que alguien te ha comentado en el bar que una tía murió en un hospital y tu lo has adornado con muchas palabras pero no dices nada que no se sepa desde el titulo. Espero que la mayoría de los comentarios sean de amigos tuyos, porque si los has escrito tu mismo eres muy triste.
Osea, mierda pero de verdad. Así se hace bien, toma nota: Te voy a contar cuando mi madre se mato con un bug del coche. El coche no frenó, desde entonces le prestan mucha atención a los frenos. Ves? mi articulo es 10 o 100 veces mejor porque no te hace perder el tiempo.
====
Informático desde que tengo memoria y editor ¿en jefe? de Tecnovortex desde sus orígenes. Fotógrafo amateur, audaz cocinero y fanático de los juegos de fútbol desde el Goal 2. Proyecto de runner. Te invito a seguirme.
====
Te digo varias cosas: que te animo a que sigas con la informática, que no me extraña que seas el editor jefe del espacio donde has colgado semejante truño porque si dependiera de otra persona estarías fuera, que sigas haciendo fotos con el ultimo móvil que te has comprado para testear la cámara, que si los huevos tienen puntillitas es porque no sabes cómo se fríe un huevo, y que se nota que solo juegas a juegos de futbol. Y ser runner NO es ir a por pan dando saltitos.
Aprende a escribir diciendo algo, pringao.
pd: Faltan tildes y esas cosas, pero no merece la pena corregir, total, el que lo va a leer eres tú.
pd2: Guille, deberías dejar la bebida, que ya se te va notando.
-PatMa
Anónimo: Quiero pedirte disculpas por hacerte perder tu valioso tiempo.
Ahora, te pregunto: ¿Es necesario tanta saña y mala leche conmigo?
Pensalo.
JAJAJA de donde salio este personaje? No es que venga en defensa de Guillermo, calculo que el solo sabe defenderse, pero vengo a expresar mi desacuerdo con «anonimo».
Soy seguidor del blog, sus articulos y opiniones, uno puede estar o no de acuerdo, pero no porque esto sea internet puede aparecer alguien asi porque si de la nada comentar semejante barbaridad.
Creo que el «sentido de la justicia» me obliga a a responderte, si no te gusta podes pasar por mil sitios hasta encontrar uno que te agrade y te caiga simpatico, no es necesario faltarle el respeto a nadie insultando sin motivos, esto es un espacio para compartir y comunicarse, no se con que tipo de personas estas acostumbrado a mantener dialogos, pero definitivamente no pareces ser alguien educado, lo demostraste con tu opinion, expresandola de la peor manera posible.
Cada quien hace lo que quiere con su vida personal, descalificar a alguien en base a sus gustos o costumbres me parece espantoso. pero pareciera que te ofendiste en algun punto y no logro entender el motivo.
Te animo a escribir tus propios articulos, no es muy dificil abrir un blog o encontrar un espacio para hacerlo.
Saludos y exitos a todos! Abrazo!
Lo que pasa es que es mucho mas fácil criticar, destruir, o lo que sea, que ponerse a hacer algo.
Y estos personajes (si los conoceré) tienen una increíble capacidad para la crítica. Se creen con condiciones para decirle al que hace algo lo que tiene que hacer ya que es muy malo (según él) para lo que hizo.
Son Trolls, de los verdaderos y de los buenos. Éste es un ejemplo de Troll, no de los que se habla ahora en los medios.
A ver… está perfecto que se exprese, el tema es la mala leche y la forma en la que lo hace ya que en todo momento escribe como si se tratara de un ser superior y su opinión es mejor que la de los demás.
Y ponele que es una mierda lo que hago, es probable y está todo bien con eso, vivo con ello. Ahora… ¿cuál es el problema? Al menos yo lo sigo haciendo porque me gusta y por lo que veo a algunas personas también le gusta o le parece interesante al menos
Yo trabajo en un sanatorio y como dijeron en algún comentario la mayoria (otro si lo hacen) de los equipos de Tomografía, Resonancia, Rayos, Ecografía, Medicina Nuclear, no trabajan bajo Windows, sino que tienen sistemas embebidos o sistemas operativos propios muy especificos. En mi caso, además de dar soporte interno, soy programador y he desarrollado las interfaces y middelware para los equipos autoanalizadores de laboratorio (que en este caso, la mayoria sí trabaja bajo sistemas Windows, algunos standard y otros especiales) y en el tiempo que llevo haciendo esto (mas de 8 años) he desarrollado muchos protocolos distintos, de equipos mas antiguos hasta los mas modernos, desde simples ASCII vía RS232 hasta ASTM Standard E 1381/1394 o HL7 (https://es.wikipedia.org/wiki/HL7) por protocolo TCP. Los controles que se realizan son exhaustivos, se realizan muchas pruebas antes de poner en producción el software, internamente los protocolos de comunicación tienen metodos de control con señales, se verifica la integridad de los datos mediantes los standares electricos de los cables comunicación y también por medio de Checksums (por ejemplo por modulo-256). Además se realizan validaciones cruzadas de resultados intraequipos que realizan los mismos análisis, para cada caso existen alarmas que son exhibidas a los operados quienes deben validar por duplicado los datos antes que vayan a parar a la historia del paciente e incluso hay datos que no se permiten validar bajo ningún concepto si no cumplen con condiciones básicas de integridad de las muestras, etc…
Con todo esto a lo que quería llegar es a que si bien, este caso que se comenta es cierto, muchas veces se le achacan errores a los sistemas o «aparatos» cuando el problema es de criterio profesional (médico). Hoy en día hay miles de controles que se realizan por software (mediante validaciones, alarmas, standares, logs, etc) y por hardware (por ejemplo mediante sensores y registros).
Nunca escucharon a personas decir, «… debe ser un error del sistema…» o «… seguramente se colgó el aparato…», muchas veces el problema es un problema de mala utilización o de falta de capacitación. Y por otro lado está, según mi opinión, un tema de criterio médico en la definición de los tratamientos, seguimientos, controles, etc.
Puedo decir también, que es cierto que he visto mucha gente que se dedica a desarrollar software para cuestiones de importancia (por ejemplo el caso de la nota) que no tiene el compromiso suficiente con lo que está haciendo, incluso, que ni siquiera sabe básicamente sobre lo que está programando. Si yo soy Contador de una empresa constructora, minimamente debería manejar los términos del ambiente e incluso un poco mas, saber que diferencias hay entre los materiales o en que casos corresponden cantidades para determinados proyectos. Esto mismo lo llevo al ámbito de la programación… si me dedico a hacer software de contabildiad, debería saber como funciona el IVA o los IIBB, o conocer las últimas resoluciones de la AFIP… si soy programador de sfotware para equipos de laboratorio, debería saber de que hace cada equipo y que impacto tienen los análisis que estos procesan, incluso poder interpretar básicamente que información devuelve cada análisis.
Resumiendo, creo que en todos los ámbitos, no solo en el desarrollo de software, hay un problema de compromiso con lo que se está haciendo y no se toma real conciencia del impacto que puede tener lo que uno hace.
Perdón por lo largo del post.
Saludos.
Si no recuerdo mal, HL7 lo usan los chinos de Mindray, que da la sensación que las interfases las hicieron los programadores a punta de pistola. Doy fe porque desarrollamos sistemas para laboratorios. La misma versión del equipo, por ejemplo, BS-200, vendido por una empresa es un modelo, vendido por otra, aunque desde afuera sea igual, el software es igual, pero la interfase es distinta.
Además, en uno de los campos de HL7 se declara en qué se codifica (ANSI o UNICODE). Las strings que envía el BS dice UNICODE, pero las codifica en ANSI… un verdadero dolor de cabeza. 5 días completos para dejar en marcha la interfase con el BC-5380 (contador hematológico).
HL7 es un protocolo de mensajes integral para salud, no solo para laboratorios. Es cierto lo que decis sobre las distintas marcas para un mismo modelo, incluso pasa cuando se hacen actualizaciones de software de los autoanalizadores, pero generalmente uno puede elegir si utilizar la nueva versión o no.
El tema de la codificación de caracteres siempre es un tema cuando tenés que vincular sistemas. Pasa con XML, WS, Json, HL7, etc..
Hola Pai, no sé si vayas a ver este mensaje ya que este post fue publicado en el 2017. Me gustaría poder contactarte en privado, me estoy adentrando en el mundo de HL7 y acorde a todo lo que has redactado en tu respuesta, puedo ver que dominas ampliamente el tema.
Por si lees esta respuesta, te dejo mi correo de gmail: sjimenezr20, te agradecería infinitamente si pudieses escribirme. Mi nombre es Vanessa, soy de Perú, y es muy difícil encontrar expertos en HL7 a quien pueda dirigirles mis preguntas respecto a este estándar. Que tengas un buen día!
para leer:
https://es.wikipedia.org/wiki/An%C3%A1lisis_modal_de_fallos_y_efectos
Trabajo en el banco de sangre de Irlanda, y aca una caida del sistema le puede costar la vida a varios ya que todo el seguimiento de la sangre/plaquetas/plasma/pacientes/donantes se hace a travez de una app.
Me ha pasado de gente llamandome desesperada porque una bolsa de sangre para un bebe tenia que salir urgente y la app estaba colgadisima y no podian escanear la bolsa antes de mandarla. El bebe estaba en cirugia, asi que cada Segundo cuenta. Se podran imaginar lo contento que estaba el flaco.
Hoy por hoy, en la busqueda de optimizacion de procedimientos se relega muchas cosas a los sistemas, que SIEMPRE pueden fallar, no importa cuando, si en 1 semana o 10 años, sabes que algun dia se va a ir a todo al carajo y todo va a depender de que tan rapido puedas reiniciar el server y hacerlo funcionar como es debido.
Lo mismo que puso Pai mas arriba, si no estas empapado en como es que funcionan las cosas aunque sea a nivel basico, no podes comprometerte completamente con tu trabajo. Aca hay una induccion muy grande, no importa de que area seas finanzas/it/marketing/etc, a todo Nuevo empleado se le da un curso intensive de como funciona todo el complejo. Aca se procesan todas las donaciones de sangre del pais, corneas, corazones y piel, asi que se hace un laburo bastante importante. Y como es estatal, las auditorias son un dolor de huevos, no dejan pasar una.
NdR: Este teclado no tiene acentos.
Excelente comentario Mum. Tremendo aporte.
Gracias por avisar, más que nada para los trolls que me matan por no poner un acento
Por el amor a todo lo bueno y puro que todavía existe en el mundo! por que en Dios no creo que crea este señor anónimo.
Por lo visto este señor llego en modo ira y no desperdicio tiempo en gastarse los fósforos y el combustible.
Menos mal que no existe tecnología que virtualice en tu monitor semejantes sentimientos si no saldría un puño del mismo y partiría un ojo, o te arrojan una antorcha!
Por lo visto es muy peligroso tener un Blog sin saber de lo que se habla… Esto es un blog, no!? Si no, pido disculpas de antemano por todo lo dicho y por lo posibles horrores ortográficos antes que quieran clamar por mi sangre. ;P
Le pasa a los «mejores«.
Imagínense cuando se buguee el wifi y nos fría los renacuajos
Hay algunos casos más recientes, como el que le sucedió a los boings 737 Max, que provocaron que dos aviones se estrellaran. No fue a caso un error del software, acompañado de la nula capacitación a los pilotos para poder entender cómo se comportaba el avión ante determinados escenarios?
El problema fue que esto ocurrió porque en esa versión de la máquina, a diferencia de la anterior, no había un «candado de hardware» que impidiera el error de la bruta descarga. Esto es porque antes había un fusible físico que se rompía, pero acá solo uno vía software… El cual fallaba debido a que la operadora tipeaba muy rápido.
https://www.youtube.com/watch?v=v5mfyj0S2Ss
ese video esta buenisimo y explica esto de forma bastante didáctica. Es un caso que me aterra bastante.