La visión de TI sobre los errores del software médico

Esta semana estuve en el evento Healthnology México y la mejor presentación por lejos fue la de Jesús Díaz (CIO en CHRISTUS MUGUERZA) donde interactuaba con el público presentando una frase sobre la implementación de sistemas clínicos y preguntaba “¿es mito o realidad?”.

Estuve muy de acuerdo con todos los mitos que presentó hasta que hizo la siguiente pregunta, a la que yo y otros médicos dijimos “Mito”, pero él puso “Realidad


Y luego indicó que los médicos somos muy poco tolerantes a las fallas de los sistemas .

En mi incapacidad de no tomar partido expresé mi punto de vista. Los médicos somos amantes de la tecnología médica y la implementamos en cuanto vemos que esa tecnología aporta al cuidado de los pacientes. La medicina se resetea cada 5 años, así que para estar al día uno tiene que estudiar e incorporar nuevos procedimientos, medicamentos, test diagnósticos, etc. Son los médicos los que están pidiendo siempre que por favor se compre el último instrumental quirúrgico o se apruebe el último fármaco publicado en las revistas que leemos.

Somos “resistentes” a cualquier tecnología que no aporta valor en la atención de los pacientes que tratamos , y esto sigue siendo muy común en los débiles sistemas de información que se implementan. Si un formulario estructurado con campos obligatorios entrega “información a la dirección” pero no aporta al cuidado de ese paciente individual, es visto como un obstáculo y no como un aliado en esa atención. Y peor es si el software falla de forma sostenida para un flujo clínico . Es difícil para una persona que no ha atendido pacientes entender lo que está en juego en cada flujo de atención.

Siempre me divirtió la comparación que se hace de la medicina con la aviación preguntándose cómo puede ser que no tengamos los mismos estándares de seguridad que tiene la aviación. Un error en el software clínico que genera problemas para la atención del paciente es vivido por el profesional de forma similar a un error en el software de un avión (que se prenda, por error, la luz de falta de combustible, que deje de funcionar el piloto automático, que aparezca, o no, la alerta de sobrecalentamiento de motores). Al igual que el piloto que teme por su vida y la vida de los pasajeros del avión, el médico teme por su licencia profesional y por la vida de los pacientes que tiene a su cargo.

¿Cómo creen que será el diálogo entre el piloto con el desarrollador, o quién está a cargo de la operación del software del avión que falló?

Por lo tanto, mi recomendación a las personas de TI, cuando el software presente un error sistemático que no permita realizar correctamente un flujo clínico, y por el que los médicos y enfermeras “hagan escándalo” es:

  1. Mantener la calma
  2. Intentar no dar explicaciones técnicas como “se cayó el webservice X”, “hay latencia en los sistemas” o “es un caso de borde no contemplado por el software”
  3. Pedir disculpas por poner en riesgo en la atención de los pacientes y trabajar sin parar para resolver el problema lo antes posible

Hola Alejandro,

como sugerencia para situaciones como "software falla de forma sostenida para un flujo clínico" es anticiparnos para que los sistemas y aplicaciones puedan cumplir con el objetivo de interoperabilidad y atención efectiva en el paciente a través de las metodologías ágiles como alternativa a la gestión tradicional de cascada; la gestión de proyectos de cascada

implica toda la planificación por adelantado antes de comenzar cualquier trabajo.

Así es como las organizaciones de salud tradicionales han estado trabajando. Para comenzar, las organizaciones de atención médica pueden mirar los departamentos que ya podrían ser ágiles, como TI o el departamento de innovación de atención médica, y si no, comenzar a adoptar ágilmente de
aquellos departamentos donde es más fácil seguir. Crear equipos interfuncionales y aumentar la comunicación y el compromiso: las organizaciones de atención médica deberían considerar alejarse de una estructura jerárquica para tener equipos interfuncionales. Los equipos interfuncionales generalmente consisten en colegas con diferentes

áreas de especialización y disciplina.

Mayor colaboración con los clientes: los hospitales pueden considerar colaborar más con los pacientes para obtener comentarios regulares sobre los servicios recibidos. Involucrarlos en el
piloto para nuevas aplicaciones o servicios y obtener la retroalimentación puede ayudar en el aprendizaje continuo y seguir las mejoras que son la parte muy importante de ágil.

Pero esto es sin duda un cambio cultural. La persona que integra un equipo ágil debe aprender los principios y valores que sustentan esta forma de relacionarse y organizarse de manera efectiva para obtener resultados, y también debe identificar los nuevos paradigmas que favorecen la aparición de los comportamientos productivos, con un propósito claro: alcanzar el resultado esperado de la manera más efectiva, en el menor tiempo posible y minimizando los costes.

Como conclusión es importante poder entender el proceso y el objetivo para el cual se crea el sistema y la aplicación y acompañar el desarrollo con una cultura del equipo y metodología ágil; permitirá favorecer a través de las pruebas que se generen llegar al cumplimiento de sustentar y favorecer al paciente en todo su ciclo de asistencia.

Espero pueda ser de utilidad mi comentario.

Saludos cordiales y siempre es un gusto poder recibir información de tu parte.

MS