Factores Humanos

Para la

Seguridad de la Tecnología Sanitaria Evaluando y Mejorando

El Uso de la

Tecnología de Salud

En el Mundo Real

Andras Cassano-Piché, Patricia Trbovich, Melissa Griffin,

Ying Ling Lin and Tony Easty

Human Era @ UHN Global Centre for eHealth Innovation

University Health Network

International Federation of Medical and Biological Engineering

Clinical Engineering Division

Traducción al español: Vladimir Quintero

Cover design: Brent Bily -Envisioneering

i

Prólogo Una de las características del campo de la salud es su constante y extremadamente

rápido desarrollo tecnológico. En el pasado su progreso se basó en el conocimiento procedente principalmente de la medicina, si bien en la actualidad distintas áreas de conocimiento contribuyen: como la electrónica, la química, la biología, la física, las matemáticas, la ingeniería mecánica, ingeniería de materiales, y la informática.

Este rápido desarrollo ha producido una inmensa variedad de equipos de gran aceptación, así como de procedimientos médicos para el diagnóstico y la terapia. Esto hace necesario el desarrollo, la transferencia y la adaptación de programas de seguridad, anteriormente desarrollados en otras industrias, que se implementarán en los procedimientos médicos, así como en la operación, diseño y producción de equipos, en la interoperabilidad de registros médicos, almacenamiento en la nube, etc.

Los Ingenieros Clínicos, acostumbrados a tratar principalmente con técnicas de gestión de equipos médicos, se vieron abrumados por las exigencias de seguridad asociadas con el uso de tales tecnologías. Es más, pocos académicos de todo el mundo están familiarizados con los programas de seguridad aplicados al área de la salud.

Como uno de los participantes en la ejecución del plan de estudios para los cursos de formación de ingeniería clínica, y el coordinador de uno de esos cursos de formación durante más de 20 años en Brasil, estoy emocionado por el lanzamiento de este libro, explicando el uso práctico de la seguridad de herramientas de los ingenieros clínicos y tecnólogos.

Como investigador y supervisor de un programa de Ingeniería Biomédica de post-grado en la Universidad de Campinas durante más de 30 años, tuve varias oportunidades de discutir con mis estudiantes y coordinadores de cursos de formación de ingeniería clínica, temas relacionados con la gestión de riesgos para el área de la salud. Estas discusiones fueron sobre la urgente necesidad de incluir herramientas de seguridad y los programas dedicados a los entornos sanitarios dentro de nuestro programa académico de Ingeniería Clínica. A pesar de nuestra creencia en la urgencia de este trabajo, fue extremadamente difícil encontrar instructores familiarizados con este tema. Los que hemos encontrado, a pesar de un gran conocimiento sobre herramientas de seguridad muy eficientes, no tenían idea de cómo traducirlo al área de la salud. Es importante mencionar que mi participación como presidente de la División de Ingeniería Clínica de la Federación Internacional de Ingeniería Médica y Biológica - CED / IFMBE, me demostró que esto no es sólo un problema local, sino una falta de conocimientos en todo el mundo.

En 2011, tuve el privilegio de trabajar con el grupo HumanEra, de la University Health Network de Toronto, Canadá, especializado en el uso de herramientas de factores humanos en el campo de la salud. Fui testigo de la importante labor que realizaban para el Ministerio de Salud y Cuidado a Largo Plazo de Ontario, llevando a cabo estudios e investigaciones preventivas sobre eventos adversos dentro del área de la salud. Los resultados y las

ii

conclusiones obtenidas produjeron recomendaciones para mitigar los riesgos asociados con el uso de tecnologías de la salud.

También me di cuenta de que algunas de las herramientas de ingeniería de factores humanos (HFE) podrían utilizarse, con relativa facilidad, para desarrollar programas de seguridad. A partir de entonces, persistentí para que HumanEra escribiera un libro que describiera cómo estas herramientas pueden ser utilizadas por los ingenieros clínicos para desarrollar e implementar programas de seguridad en el entorno sanitario.

Afortunadamente en 2014, encontraron tiempo para dedicarse a la elaboración de este libro. Con años de experiencia en el uso práctico de herramientas de HFE, el equipo HumanEra sabía exactamente qué tipo de conocimiento previo deben tener los ingenieros clínicos antes de aprender sobre el uso de este tipo de herramientas. Por lo tanto, los capítulos iniciales de este libro explican lo que es necesario aprender antes de la presentación de las herramientas HFE.

El libro también da una explicación de otras herramientas como el análisis de modo de fallos y efectos adversos(AMFE) y el análisis de causa raíz (RCA), que también han sido adaptados y utilizados en el entorno sanitario. Muestra cómo estas herramientas pueden aplicarse en combinación con otras herramientas de HFE, para descubrir los problemas subyacentes que comprometen la seguridad en la asistencia sanitaria.

Creo que la mejor característica de este libro es la forma en que se presentan las herramientas de HFE. En él se explica no sólo "Qué" hacer, sino también "Cómo" para desarrollar las actividades necesarias para poner en práctica un programa de seguridad en el entorno sanitario. Se muestran ejemplos detallados sobre cómo desarrollar todos los documentos que forman parte del proceso de investigación, y lo que debe conocere de las personas involucradas, ya sea en eventos adversos o simulaciones. También proporciona, en un lenguaje sencillo, todos los pasos necesarios para crear la herramienta de simulación, así como cuándo y cómo llevar a cabo un análisis de tareas. Junto con el análisis heurístico, estas tres herramientas proporcionan amplias posibilidades no sólo para la investigación de los eventos adversos, sino también para su mitigación.

En resumen, este libro no sólo le da una visión teórica de "qué" hacer al aplicar las herramientas HFE sino "cómo" pueden aplicarse; todo a través de casos de estudio. Después de leerlo, los ingenieros clínicos deben seguir adelante para desarrollar un programa de seguridad en el área de la salud en la que están trabajando.

El contenido de este libro también se puede utilizar fácilmente y transformar en conferencias a cargo de especialistas clínicos de ingeniería con la misión de diseñar e implementar una disciplina de seguridad en salud dentro de los cursos de formación Ingeniería Clínica.

Por último, con respecto a la implementación de programas de seguridad en el entorno sanitario, los ingenieros clínicos tienen ahora una fuente muy útil de información que estará disponible gratuitamente en la web, proporcionada por el equipo HumanEra y patrocinado por la División de Ingeniería Clínica de la Federación Internacional de Medicina e Ingeniería Biológica - CED / IFMBE.

Profesor Saide Calil, UNICAMP, Campinas Brasil. Mayo de 2015

iii

Prefacio Gracias por leer este libro y dar un paso adelante en la exploración del papel que los

factores humanos pueden desempeñar para ayudar a mejorar la seguridad en la tecnología sanitaria. El uso de la tecnología médica está en aumento a nivel mundial, aportando grandes beneficios para los pacientes. Sin embargo, la tecnología sanitaria no siempre se comporta como se pretende, y su uso puede ser difícil y confuso. Con demasiada frecuencia, esto conduce a eventos adversos. La buena noticia es que hay métodos que pueden aplicarse para ayudar a identificar y superar estos problemas, y ese es el objetivo de este libro.

A menudo, las personas más indicadas para participar en este enfoque son quienes realizan el servicio y el apoyo de la tecnología en la asistencia sanitaria. En algunos entornos, este será un gran equipo de personas, incluyendo ingenieros y tecnólogos. En otros, puede ser un técnico solitario que hace lo que él o ella puede para dar apoyo. Este libro se refiere al "profesional de la tecnología biomédica". Elegimos este título cuidadosamente, deseando que sea lo más inclusivo posible, y relevante para diferentes entornos, y de distinto poder adquisitivo (alto, mediano y bajo).

No importa dónde trabaje, le animo a que lea este libro y comience a aplicar algunos de los métodos descritos aquí. Al principio, pueden parecer un poco difíciles de seguir, pero no hay nada mágico en ellos, y pueden conducir a resultados sorprendentes. Una vez que comience a ver por sí mismo lo útil que estos métodos pueden ser, estoy seguro de que estará atrapado, al igual que me ocurrió a mí cuando empecé a utilizarlos. Estos métodos cambian la forma de ver la tecnología y su papel en nuestro mundo, y pueden marcar una gran diferencia para la seguridad del sistema sanitario en el que trabaja.

Muchos de los ejemplos se basan en nuestras experiencias en Canadá, pero en cierta medida reflejan problemas específicos de nuestro sistema, así que cuando lea el libro, por favor sustituya los ejemplos con lo que ha experimentado directamente en su propio ambiente de trabajo. Estoy seguro de que identificará rápidamente las tecnologías que podrían beneficiarse de los enfoques descritos aquí y le animo a que empiece a aplicarlos.

Me gustaría dar las gracias a los coautores de este libro, que han trabajado duro para tratar de asegurar que los métodos descritos sean lo más accesibles posible. También me gustaría dar las gracias a los revisores, cuyos comentarios han ayudado de muchas maneras a mejorar y aclarar los mensajes que buscamos compartir. Los errores y omisiones son responsabilidad exclusiva de los autores. Le agradezco especialmente al profesor Kim Vicente, de la Universidad de Toronto, quien me abrió los ojos sobre el poder y la relevancia de estos métodos y me ayudó a aprender a aplicarlos. ¡Una experiencia verdaderamente cambiante! Por último, quisiera agradecer a la División de Ingeniería Clínica de la Federación Internacional de Ingeniería Médica y Biológica ya su Presidente, el Profesor Saide Calil, por encargarnos la redacción de este libro. Sin este apoyo invaluable, no habríamos podido completar este trabajo.

Tony Easty, Toronto, Canadá. Mayo de 2015.

iv

Agradecimientos Estamos extremadamente agradecidos al profesor Saide Calil por su visión y estímulo.

Calil fue el catalizador de este libro y logró obtener fondos de la División de Ingeniería Clínica de la Federación Internacional de Ingeniería Médica y de Biomateriales, a quienes agradecemos sinceramente.

Aunque sólo algunos de los miembros de HumanEra formalmente han sido los autores de este texto, este libro es realmente el trabajo de todo el equipo. Cada miembro del equipo, con su formación, experiencias y pasión, ha ayudado a evolucionar cada uno de los métodos presentados en este libro. Bajo el liderazgo de Tony Easty y Patricia Trbovich, los miembros de HumanEra incluyen: Andrea Cassano-Piché, Christopher Colvin, Mark Fan, Rachel Gilbert (nee White), Melissa Griffin, Caterina Masino y Sonia Pinkney. HumanEra también ha tenido el privilegio de trabajar con muchos estudiantes dedicados y talentosos a lo largo de los años, uno de los cuales fue coautor de este libro (YLL). Gracias a todos nuestros estudiantes por sus valiosas contribuciones a nuestros proyectos.

HumanEra ha tenido el placer de colaborar con personas y organizaciones enérgicas y dedicadas en el ámbito de la seguridad sanitaria. Muchas de estas personas han contribuido generosamente a la revisión de una o más secciones de este texto. Estas personas son: Sandra Ahedo González-Zabaleta, Fernando Andrade, Guilherme Araujo Wood, Victor Batista Tsukahara, Ann Blandford, Saide Calil, Peter Doyle, Karina Gomide, Julie Greenall, Laura Herrero Urigüen, Sylvia Hyland, Leonardo Novaes Nascimento, Ryan Pinto Ferreira, Kim J. Vicente, y Carlos Alessandro Bassi Viviani

Los autores desean agradecer al Instituto Canadiense para la Seguridad de los Pacientes, al Instituto de Prácticas Seguras de Medicamentos de Canadá y a Carmen Olson, quienes han dado permiso para reutilizar sus textos y materiales fotográficos a lo largo de este libro. También queremos agradecer a Brent Bily por su generosa contribución del diseño de portada y Chris Colvin por diseñar y editar figuras y tablas a lo largo del texto.

Finalmente, queremos agradecer a nuestras familias por su apoyo incondicional a nuestro trabajo, nuestro equipo y nuestra visión de la seguridad sanitaria global. Gracias Chris Piché por ser mi campeón y ayudarme a ver las posibilidades y Gus y Gabriella Cassano por ser mi ejemplo de hacer lo que sea necesario para la busqueda del cambio y la mejora(ACP). Gracias Gordon Lavergne por inyectar "joie de vivre" en nuestras vidas y por apoyarme a perseguir mis pasiones (PT). MG agradece a Mike Kozak por su aliento y apoyo, y por hacerme reír. YL agradece a Yen Chi Liu, a Jiunn Long Lin y a Steven Roy que me apoyaron sin dudar y al equipo de HumanEra por brindar mentores únicos y sobresalientes. Muchas gracias a todas las organizaciones que han apoyado nuestro trabajo en esta área, y especialmente a Beth Savan por su constante apoyo y estímulo (AE).

v

Prólogo a la versión en Español

Si bien es cierto que el desarrollo estructurado de conceptos y metodologías alrededor de factores humanos y ergonomía se remonta a mediados del siglo pasado, durante la Segunda Guerra Mundial, con un enfoque que progresivamente evolucionó hacia la busca de un ´balance entre comodidad y seguridad, pasando por la usabilidad´, su aplicación formal en el área de la salud es relativamente reciente, estimulada particularmente por el crecimiento y diversificación de la tecnología disponible a partir de la masificación del uso los microprocesadores, de la digitalización de la información y de la convergencia tecnológica producto de la Tercera Revolución Industrial.

De la mano de este fenómeno digital, la expansión del ámbito de acción e impacto de los factores humanos ha llegado a la mayoría de los sectores y actividades de la economía y el desarrollo científico a nivel mundial. El contexto de la tecnología, incluida la sanitaria, en el corto período desde la aparición de la primera versión de este libro, ha experimentado modificaciones significativas, producto del nuevo ciclo de convergencia tecnológica, de los avances en nanotecnología, computación, nuevos materiales y en especial la aparición disruptiva de Internet de las Cosas (IoT) y los dispositivos (plataformas) móviles de comunicaciones y computación, que están caracterizando la Cuarta Revolución Industrial.

La tendencia a promover la atención domiciliaria y la atención a distancia de salud, así como a estimular el enfoque preventivo, presente en los modelos de salud en casi todo el mundo, junto a esta creciente disponibilidad de tecnología, multiplica los actores en los procesos de atención y monitoreo de salud, en entornos que van más allá de las instituciones sanitarias.

La irrupción masiva de Internet de las Cosas y de las comunicaciones celulares, no solo ha incrementado la diversidad, funcionalidad y ubicuidad de los dispositivos médicos, sino que ha traído a la escena a un nuevo actor: el usuario, que puede no solo interactuar directamente con ellos, sino también generar datos e intervenir en su forma de producción, almacenamiento y distribución. El aumento de dispositivos médicos, incluidos aquellos que aún no están formalmente aceptados como tal y que frecuentemente, a pesar de su uso masificado, no cuentan con la aprobación de las autoridades reguladoras para ser usados como dispositivos medicos (ej: aplicativos móviles) disponibles a un número mayor de usuarios, incrementa el riesgo en forma inevitable y hace que el universo de aplicación de Factores Humanos crezca en significativamente, involucrando especialidades de la Ingeniería que no eran tan obvias hasta hace poco tiempo. Es por ello que la aparición de esta versión en Español tiene como objetivo, no solo atender al creciente número de Ingenieros Clínicos y Biomédicos y profesionales hispanoparlantes interesados en el tema, sino que espera también llegar a otros ingenieros, que de hecho ya han entrado a formar parte del ecosistema de la tecnología en salud. Bienvenidos todos a bordo !

vi

Deseo expresar mi agradecimiento a la Federación Internacional de Ingeniería Médica y Biológica por haber apoyado esta iniciativa, a las dos revisoras de la versión en Español, Laura Herrero Urigüen de la Fundación Instituto de Investigación Marqués de Valdecilla (IDIVAL) y Sandra Ahedo Glez-Zabaleta del Instituto de Investigación Sanitaria Biodonostia, por su exhaustivo y profesional desempeño, a la Universidad Simón Bolívar por la asignación de tiempos y recursos para realizar la traducción, y especialmente a nuestros muy queridos amigos Antonio Hernández de la ACCE y Tony Easty de la Health Network/Univeristy en Toronto por su continuo apoyo y gestión institucional.

Vladimir Quintero, Universidad Simón Bolívar, Barranquilla, Colombia. Febrero 2018.

vii

Tabla de contenido Prólogo i

Prefacio iii

Agradecimientos iv

Prólogo a la versión en Español v

Tabla de contenido vii

Introducción 1

Como usar este libro 5

Parte I La Importancia de los Factores Humanos en la Gestión de Tecnología en Salud 7

Capítulo 1. Gestión Tradicional de Tecnología en Salud 9

Capítulo 2. Factores Humanos: Evolución de la Cabina de Mando a las Salas de Operación. 11 Sección 2.1 Introducción 11 Sección 2.2 Historia 11 Sección 2.3 Por qué aplicar Factores Humanos a la atención de la Salud? 12 Sección 2.4 Indicaciones observables que apuntan a problemas subyacentes de Factor Humano. 13 Sección 2.5 Cómo pueden los Profesionales de la Tecnología Biomédica Ayudar a mejorar la

Seguridad del Paciente. 14

Capítulo 3. Pensando en Factores Humanos 16 Sección 3.1. La división mecanicista-humanista 16 Sección 3.2. La escala humano-técnica 17 Sección 3.3. Introducción a la Ingeniería Cognitiva 18 Sección 3.4. Modelo de queso suizo de Reason para la causa de accidentes 21 Sección 3.5. Jerarquía de la Efectividad 23

Parte II Manual de Métodos de Factores Humanos 27

Recopilación de Datos para Comprender a los Usuarios y el Entorno de Uso 28

Capítulo 4. Observación 29 Sección 4.1. Preparando el escenario 29 Sección 4.2. ¿Qué son las Observaciones? 29 Sección 4.3. ¿Por qué Utilizar Observaciones? 29 Sección 4.4. Cuándo usar Observaciones 30 Sección 4.5. Preparación para la Recopilación de Datos en la Observación 31 Sección 4.6. Recopilación de datos por observación 35 Sección 4.7. Qué hacer con los datos de observación 39 Sección 4.8. Limitaciones de las Observaciones 42 Sección 4.9. Observaciones adicionales Recursos 43

Capítulo 5. Entrevistas, grupos focales y encuestas 44 Sección 5.1. Preparando el escenario 44 Sección 5.2. Entrevistas 45 Sección 5.3. Grupos focales 47

viii

Sección 5.4. Encuestas 50 Sección 5.5. Qué hacer con la entrevista, el grupo focal y los datos de la encuesta 54 Sección 5.6. Recursos adicionales para entrevistas y grupos focales 54

Capítulo 6. Análisis de tareas 55 Sección 6.1. Preparando el escenario 55 Sección 6.2. ¿Qué es el Análisis de tareas? 55 Sección 6.3. ¿Por qué utilizar el Análisis de tareas? 55 Sección 6.4. Cuándo utilizar el análisis de tareas 57 Sección 6.5. Preparación para un análisis de tareas 57 Sección 6.6. Completar un análisis de tareas 59 Sección 6.7. Qué hacer con un análisis de tareas completado 61 Sección 6.8. Limitaciones del análisis de tareas 61 Sección 6.9. Recursos adicionales de análisis de tareas 64

Métodos de evaluación de factores humanos 65

Capítulo 7. Análisis heurístico 66 Sección 7.1. Preparando el escenario 66 Sección 7.2. ¿Qué es el análisis heurístico? 66 Sección 7.3. ¿Por qué utilizar el análisis heurístico? 68 Sección 7.4. Cuándo utilizar el análisis heurístico 68 Sección 7.5. Preparándose para el análisis heurístico 69 Sección 7.6. Completar un análisis heurístico 73 Sección 7.7. Qué hacer con un análisis heurístico completo 74 Sección 7.8. Limitaciones del Análisis Heurístico 75 Sección 7.9. Recursos adicionales 77

Capítulo 8. Pruebas de usabilidad 78 Sección 8.1. Preparando el escenario 78 Sección 8.2. ¿Qué es la prueba de usabilidad? 78 Sección 8.3. ¿Por qué usar pruebas de usabilidad? 78 Sección 8.4. Cuándo usar pruebas de usabilidad 79 Sección 8.5. Preparación para una prueba de usabilidad 79 Sección 8.6. Completar una prueba de usabilidad 101 Sección 8.7. Qué hacer con los resultados de la prueba de usabilidad 104 Sección 8.8. Pruebas de Usabilidad Comparativa 108

Factores Humanos y Métodos de análisis Informados de Riesgo e Incidente 110

Capítulo 9. Factores Humanos, Análisis Informado de Modo de Fallo y Efectos 111 Sección 9.1. Preparando el escenario 111 Sección 9.2. ¿Qué es HFFMEA? 111 Sección 9.3. ¿Por qué utilizar HFFMEA? 112 Sección 9.4. ¿Cuándo usar HFFMEA? 113 Sección 9.5. Completando un HFFMEA 113 Sección 9.6. Qué hacer con un HFFMEA completado 139 Sección 9.7. Limitaciones de HFFMEA 140

Capítulo 10 Factores Humanos y Análisis Informado de Causa Raíz 143 Sección 10.1. Preparando el escenario 143 Sección 10.2. ¿Qué es HFRCA? 144 Sección 10.3. ¿Por qué usar HFRCA? 144 Sección 10.4. Cuándo usar HFRCA 145 Sección 10.5. En preparación para un HFRCA 146

ix

Sección 10.6. Completar un HFRCA 146 Sección 10.7. Qué hacer con un HFRCA completado 171

Compras Informadas Factores Humanos 174

Capítulo 11. Factores Humanos: adquisiciones informadas y Proceso de implementación 175 Sección 11.1. Preparando el escenario 175 Sección 11.2. ¿Qué es HFPIP? 176 Sección 11.3. ¿Por qué utilizar HFPIP? 176 Sección 11.4. Cuándo utilizar HFPIP 177 Sección 11.5. Preparativos para HFPIP 177 Sección 11.6. Completar un HFPIP 178

Parte III. Estudios de caso: Aplicación de Factores Humanos a la Gestión de la Tecnología de la Salud 191

Capítulo 12. Estudio de Caso de Soporte de Adquisiciones 192 Sección 12.1. Crear el equipo 194 Sección 12.5. Decidir sobre el (los) producto (s) 213 Sección 12.6. Configurar los productos y el entorno 213 Sección 12.7. Planificar e implementar producto (s) 214

Capítulo 13. Identificación de Problemas e Investigación de Incidentes. Caso de Estudio 216 Sección 13.1. Investigaciones de incidentes en retrospectivas: HFRCA 216

Recursos de Factores Humanos 250

Referencias 252

Apéndice A: Confidencialidad y anonimato 258

Sobre los autores 263

1

Introducción Cuando la tecnología funciona ... pero los sistemas fallan

Los acontecimientos adversos pueden suceder y suceden en todas las organizaciones de salud porque se confía en los trabajadores de la salud para subsanar brechas de seguridad, mientras trabajan bajo presiones extremas en sistemas complejos. Esto es especialmente notable cuando se trata del uso de la tecnología de la salud. La tecnología médica se ha vuelto intrínsecamente compleja y la integración de la tecnología de la salud en sistemas de información más amplios a menudo deja brechas de seguridad que se llenan tan solo con la actitud vigilante de los trabajadores de la salud. A pesar de los grandes esfuerzos de los proveedores de salud, es inevitable que, como seres humanos, los profesionales cometan errores. La atención y la vigilancia constantes no son humanamente posibles. El hecho de que los errores se traduzcan o no en daño para el paciente depende del diseño del sistema y de su capacidad para detectar y mitigar los riesgos a medida que surgen. Esto requiere una comprensión de la ciencia de los factores humanos. La siguiente historia, basada en hechos reales, ilustra cómo los factores humanos desempeñan un papel central en la seguridad tecnológica de la salud:

Una enfermera muy experimentada trabajaba en la sala general de un hospital urbano que había comprado e implantado recientemente nuevas bombas de infusión intravenosa (IV). La enfermera estaba cuidando a un paciente mayor que estaba recibiendo líquidos intravenosos a través de la nueva bomba de infusión a una tasa de 40 mL / h. Para el confort del paciente, el médico había ordenado que se administrase morfina (1 mg / ml) por vía intravenosa a una velocidad de 2 mL/h. La enfermera preparó la medicación del paciente y colgó la bolsa de 100 ml de morfina como infusión secundaria1 (Figura 1). Ella programó la bomba para entregar la infusión a 2 mL/h, y aunque el volumen de la bolsa fue de 100 mL, intencionalmente introdujo solo 10 mL en el volumen a ser infundido (VTBI) porque quería que la bomba se detuviera y sonara la alarma cinco horas más tarde y así recordarle verificar la medicación a la paciente antes del final de su turno. La enfermera siguió cuidando a esta paciente junto con otras cinco personas, y cuando su turno terminó alrededor de cinco horas y media más tarde, fue a casa sin recordar revisar la infusión de morfina del paciente.

1 Las infusiones secundarias son un modo común para administrar dosis intermitentes de medicación

en Norte América, donde las bombas volumétricas de infusión son mucho más frecuentes que las bombas de jeringa.

2

Figura 1. Configuración de la infusión secundaria para administrar morfina al paciente

Unas horas después del cambio de turno, la enfermera de turno de noche del paciente descubrió que el paciente había muerto. El momento exacto de la muerte era desconocido y la familia del paciente no había estado presente, como se solicitó durante la planificación de atención avanzada. Una investigación posterior encontró que el paciente había recibido una sobredosis de morfina. La enfermera que programó la infusión quedó devastada por el incidente.

¿Qué salió mal en este caso? Una mirada más cercana revela que la enfermera, que programó la infusión para poder controlar con seguridad la respuesta del paciente a la morfina, no entendió cómo funcionó el modo de infusión secundaria en la bomba.

Aunque la enfermera recibió entrenamiento sobre la nueva bomba de infusión, fue sólo una sesión corta de entrenamiento, y no tuvo la oportunidad de practicar usando el modo de infusión secundaria. Adicionalmente, antes de la implementación de estas bombas, las infusiones secundarias se administraron usando un tipo de dispositivo de infusión completamente diferente, de modo que el proceso de establecer y programar una infusión secundaria en este tipo de bomba era desconocido para la enfermera. Una infusión secundaria (en Y) es una disposición de infusión en la que dos infusiones se pasan a través de una sola bomba conectando el tubo de la infusión secundaria al orificio del conjunto de tubos primario situado por encima de la bomba (véase la figura 1). Debido a la presión

3

hidrostática, la bomba entregará el líquido que sea más alto en la configuración de la infusión. La mayoría de las bombas de infusión no tienen la capacidad de identificar si se está extrayendo fluido de la bolsa primaria o secundaria; simplemente extraen fluido desde arriba, y basándose en la mecánica de fluidos de la disposición, el fluido fluirá desde cualquier bolsa que tenga la presión hidrostática más alta.

En este caso, la enfermera esperaba que una vez que se hubieran entregado el volumen de 10 ml de morfina al paciente, la bomba dejaría de funcionar sonaría la alarma para alertar a la enfermera para que regresara al lado del paciente antes de reanudar la dosis de infusión primaria; sin embargo, el modo de infusión secundaria de esta bomba (y muchas otras bombas de infusión) está diseñado para hacer sonar una alerta y volver automáticamente a la velocidad primaria una vez que se ha infundido el VTBI secundario. En consecuencia, cuando la bomba pasó de la tasa secundaria de 2 ml/h a la tasa primaria de 40 ml/h, todavía quedaban 90 ml de morfina en la bolsa, y dado que la morfina estaba colgada más alta que la otra infusión y tenían una mayor presión hidrostática, los restantes 90 ml de morfina se suministraron a una velocidad de 40 ml/h, causando la sobredosis.

Actualmente, en la asistencia sanitaria, la enfermera sería considerada culpable por haber realizado una programación incorrecta de la infusión secundaria. Después de un incidente como este, el departamento de tecnología biomédica sería consultado para determinar si la bomba había funcionado mal. Si no se encontrase ningún fallo técnico de la bomba, cualquier seguimiento adicional sería dejado a consideración del director clínico. El director clínico probablemente determinaría la causa del incidente como un error humano, amonestaría a la enfermera y luego requeriría que la enfermera se sometiera a un entrenamiento adicional en la bomba. En algunos casos, las enfermeras han sido castigadas con la finalización de su empleo o peor, con la revocación de su licencia profesional.

Aunque este enfoque de la gestión de incidentes puede ser bien intencionado, es poco probable que evite que incidentes futuros similares se produzcan en el futuro. El hecho de que la enfermera que participó en el incidente se someta a formación adicional es una solución centrada en la persona, y no aborda ninguno de los factores más generales del sistema que contribuyeron al incidente. Por ejemplo, en este caso la organización había adquirido recientemente nuevas bombas de infusión para reemplazar sus bombas originales, que no tenían un modo de infusión secundario. Ya que el personal ya estaba familiarizado con el uso de bombas de infusión para infusiones individuales, y había pocos recursos de capacitación disponibles, el personal recibió muy poca capacitación práctica. Otro factor a nivel de sistema que contribuyó en este caso fue la manera inconsistente en que la información del VTBI era manejada por la bomba. Al ejecutar una sola infusión primaria, la bomba para de funcionar y da la alarma una vez que la bomba ha entregado el VTBI programado, pero en contraste, al funcionar una infusión secundaria, la bomba suena una alarma y después cambia automáticamente a la velocidda de flujo primaria y continua bombeando el líquido que tenga la presión hidrostática más alta.

Debido a que la enfermera tuvo que administrar una infusión secundaria usando la nueva bomba pero no tenía mucha experiencia ni entrenamiento, se hizo una idea de cómo la bomba manejaría la información VTBI programada para una infusión secundaria

4

basándose tanto en sus experiencias previas con bombas, como con el modo de infusión primaria. Desafortunadamente en este caso, sus suposiciones eran incorrectas.

Para mejorar la seguridad, un enfoque de factores humanos para la gestión de la tecnología de la salud es más impactante. Factores Humanos es la ciencia dedicada a diseñar sistemas que apoyen un trabajo seguro y eficaz basado en una comprensión de las fortalezas, limitaciones, sesgos y comportamientos humanos. El diseño de sistemas de asistencia sanitaria que apoyen a los profesionales de la salud en el cuidado seguro y eficaz de los pacientes es un medio por el cual se puede mejorar la seguridad de los pacientes y de los profesionales de la salud. Adoptar un enfoque de factores humanos significa garantizar que las tecnologías sanitarias satisfagan las necesidades de los usuarios, se ajusten al entorno de uso, minimicen la oportunidad de error y promuevan la retroalimentación para permitir mejoras continuas de calidad y seguridad.

5

Como usar este libro

HumanEra fue encargado de escribir este libro por la División de Ingeniería Clínica (CED) de la Federación Internacional de Ingeniería Médica y Biológica (IFMBE) para apoyar a los profesionales de la tecnología biomédica en el uso de métodos de factores humanos

La División de Ingeniería Clínica (CED) de la Federación Internacional de Ingeniería Médica y Biológica (IFMBE) encargó a HumanEra escribir este libro para apoyar a los profesionales de tecnología biomédica en el uso de métodos de factores humanos, para mejorar la seguridad de la tecnología de salud dentro de una gama de organizaciones. Para los fines de este libro, un profesional de tecnología biomédica se refiere a cualquier persona, independientemente de su título (por ejemplo, ingeniero clínico, ingeniero biomédico, técnico de equipo biomédico, gerente de tecnología médica, gerente de materiales, administrador de tecnología de salud, administrador, clínico) responsable de gestionar la tecnología en un entorno sanitario. Si bien no se hace referencia explícita a lo largo del libro, la intención es apoyar a los líderes de seguridad de todos los papeles y títulos en sus esfuerzos por mejorar la seguridad de la tecnología en salud, así como a los estudiantes aprendan a dominar métodos de factores humanos para aplicaciones en el cuidado de la salud.

Idealmente, los profesionales de los factores humanos trabajarían junto a los profesionales de la tecnología biomédica en cada organización de salud, pero la realidad es que los profesionales de los factores humanos no son un recurso habitual en la mayoría de los hospitales. Como resultado, los profesionales de la tecnología biomédica tienen la oportunidad de desempeñar un papel emocionante e importante en liderar la integración de los enfoques de factores humanos en la gestión de la tecnología de salud para mejorar el uso seguro y eficaz de la tecnología de la salud.

Este libro proporcionará una guía práctica para incorporar métodos de factores humanos en las actividades y responsabilidades diarias de los profesionales de la tecnología biomédica. Este libro también proporcionará orientación a aquellos que buscan contratar a un profesional de factores humanos en términos de qué servicios solicitar y que resultados y productos esperar de varios análisis de factores humanos. Es importante señalar que este libro no pretende ser una revisión exhaustiva de la literatura, ni una discusión académica de los factores humanos en la asistencia sanitaria. Sin embargo, junto con los recursos adicionales enumerados en cada sección de Recursos, pretende cubrir la información necesaria para empezar a utilizar métodos de factores humanos en su organización. Cuando se utilizan correctamente los métodos de factores humanos, se puede mejorar la seguridad de los pacientes y del personal relacionados con el uso de las tecnologías sanitarias.

Este libro se divide en tres partes principales:

Parte I: La importancia de factores humanos en la gestión de la tecnología de la salud proporciona algunos antecedentes sobre las disciplinas de gestión de la tecnología

6

biomédica y factores humanos, y discute la necesidad de estas disciplinas para articularse y mejorar la seguridad de la tecnología de la salud.

Parte II: Manual de Métodos de Factores Humanos proporciona una descripción detallada de cómo llevar a cabo determinados métodos de factores humanos útiles para identificar y mitigar los problemas de seguridad de la tecnología de la salud. Estas descripciones paso a paso se basan en mejores prácticas actuales, pero si su organización no tiene los recursos necesarios para llevar a cabo los métodos exactamente como se describen, se recomienda que el método se adapte a los recursos disponibles, en lugar de no aplicar el método en absoluto.

Parte III: La Aplicación de factores humanos a la gestión de la tecnología de la salud utiliza estudio de casos para ilustrar cómo los métodos de factores humanos pueden ser incorporados en las responsabilidades típicas de los profesionales de la tecnología biomédica.

En un esfuerzo por hacer que los métodos de factores humanos presentados sean más accesibles y realistas para la comunidad global, se han reducido los requisitos para equipos especializados o costosos y se han proporcionado enfoques abreviados de los métodos siempre que sea posible.

7

Parte I La Importancia de los Factores Humanos en la Gestión de Tecnología en Salud

"La falibilidad es parte de la condición humana. No podemos cambiar la condición humana, pero sí podemos cambiar las condiciones bajo las cuales los humanos trabajan ".

-James Reason, PhD

Todas las personas, no importa cuán cuidadosas sean, tienen el potencial de cometer errores. Los profesionales de la salud entran en esta área por el deseo de ayudar a otros, pero debido a que todos los seres humanos tienen ciertas fortalezas y limitaciones conocidas, las personas a menudo pueden encontrarse en situaciones en las que los sistemas en los que trabajan los llevan a cometer errores.

En 1999, la publicación del Instituto de Medicina “Errar es humano” [1] reveló que aproximadamente entre 44.000 y 98.000 muertes prevenibles se producen cada año en los Estados Unidos, por lo que es la octava causa de muerte. Un estudio similar en Canadá mostró peores resultados sobre una base per cápita, con entre 9.000 y 24.000 muertes evitables que ocurren cada año [2]. Otros estudios en el Reino Unido [3], Nueva Zelanda [4] y Australia [5] encontraron que el 8,7%, 12,9% y 16,6% de los ingresos hospitalarios, respectivamente, se asociaron con un evento adverso. En 2013, catorce años después de que se publicara Errar es Humano, una revisión actualizada de la literatura proporcionó estimaciones aún mayores, con entre 210.000 y 400.000 eventos adversos prevenibles que ocurren anualmente en los Estados Unidos [6]. Los errores que conducen a eventos adversos y muertes prevenibles de pacientes siguen siendo un problema mundial grave.

Un evento adverso puede definirse como una ocurrencia que resulta en daño no intencional a un paciente ya sea por un acto de comisión u omisión en lugar de por la enfermedad o condición subyacente del paciente [1]. Eventos adversos, o incidentes ocurren en el continuum de la atención médica, incluyendo la sala de operaciones, el departamento de emergencias, la unidad de cuidados intensivos, la sala de medicina general, el laboratorio, la farmacia, la clínica comunitaria y el entorno de atención domiciliaria.

Muchos eventos adversos en las organizaciones de salud involucran tecnologías. Cuando una tecnología no funciona de acuerdo con sus especificaciones técnicas (por ejemplo, hay un fallo eléctrico, mecánico o de software) puede conducir a un evento adverso. Además, cuando una tecnología no está bien integrada con su entorno de uso, puede conducir a un evento adverso. Por ejemplo, la función de alarma de una tecnología puede funcionar según las especificaciones, pero cuando esa tecnología se coloca en la unidad, la alarma puede no ser audible sobre el ruido de fondo normal. Estos tipos de eventos adversos también se conocen como errores de uso.

Tradicionalmente, los eventos adversos que involucran fallos de dispositivos técnicos han sido la principal preocupación de los profesionales de la tecnología biomédica, mientras que los incidentes que involucran el contexto de uso no han recibido la misma atención, ya

8

que la mayoría de las organizaciones sanitarias identifican estos incidentes como "problemas de usuarios", dejando luego la tarea a los gerentes clínicos de identificar soluciones.

En respuesta al número de eventos adversos atribuidos al error de uso y a las pruebas que apoyan la efectividad de la aplicación de principios de factores humanos al diseño de tecnologías médicas, la Administración de Alimentos y Medicamentos de los Estados Unidos (FDA) ha elaborado una propuesta de guía [7] para la adición de la evaluación de factores humanos a las evaluaciones de tecnología realizadas como parte del proceso de aprobación de la FDA antes de incluir estas tecnologías en mercado 510 (k). Si bien estas Guías se centran en la evaluación de los factores humanos como parte del diseño de tecnologías de la salud en los EE.UU., hay muchas maneras en que los profesionales de la tecnología biomédica en todo el mundo pueden aplicar métodos y principios de factores humanos a las tecnologías incluso después de que se han implantado en una organización sanitaria. Al resaltar la importancia de que sean profesionales de la tecnología biomédica quienes identifiquen los errores de uso, y considerando la relación entre los usuarios, las tecnologías y el entorno de uso, se pueden evitar las muertes prevenibles asegurando un mejor ajuste entre los componentes del sistema.

Los capítulos 1 y 2 describirán los límites tradicionales de los profesionales de la tecnología biomédica, introducirán factores humanos, tanto desde una perspectiva general como sanitaria, y describirán cómo pueden aplicarse factores humanos al manejo de la tecnología sanitaria para reducir los errores de uso y mejorar la seguridad del paciente. El Capítulo 3 proporcionará una visión de algunos de los principios generales asociados con la ciencia de los factores humanos.

9

Capítulo 1. Gestión Tradicional de Tecnología en Salud

Una amplia gama de profesionales de la tecnología biomédica son responsables de la gestión de la tecnología en salud. Entre estos profesionales se pueden encontrar ingenieros clínicos, ingenieros biomédicos, técnicos de equipos biomédicos, especialistas en equipos clínicos, especialistas en equipos biomédicos, técnicos de laboratorio y técnicos en imágenes. El personal en estos cargos administra tecnologías en una diversidad de entornos de asistencia sanitaria y, a menudo, son responsables de planificar, seleccionar, instalar, calibrar, probar, mantener y reparar esos dispositivos. Los profesionales que gestionan las tecnologías sanitarias también desempeñan otro papel importante como traductor entre el personal clínico, administrativo y técnico dentro de una organización sanitaria, proporcionando a menudo formación y asistencia técnica en tiempo real según se requiera.

Las tareas típicas de un profesional de la tecnología biomédica incluyen:

Participar en el proceso de planificación y evaluación de las nuevas tecnologías

sanitarias.

Asegurar el cumplimiento normativo de las tecnologías de la salud mediante el

mantenimiento preventivo y correctivo.

Investigar eventos adversos que involucren el uso de tecnologías sanitarias.

Participar activamente en la formación y educación del personal técnico y médico.

Crear sistemas para gestionar el inventario de las tecnologías sanitarias.

La necesidad de profesionales de la tecnología biomédica ha surgido en respuesta a un requisito para una mejor coordinación entre la medicina moderna y la ingeniería moderna. A medida que las tecnologías del cuidado de la salud continúan siendo más complejas, las organizaciones de salud necesitan tener acceso a profesionales que puedan asesorar y apoyar a los clínicos y administradores sobre asuntos relacionados con la evaluación, implementación, mantenimiento, soporte y gestión de estas tecnologías.

En general, los profesionales de la tecnología biomédica, que pueden diversas formaciones, están capacitados para evaluar, gestionar y resolver problemas relacionados con sistemas de tecnología sanitaria utilizando conocimientos basados en la ingeniería mecánica, eléctrica y de software, así como de medicina y negocios [8]. Aunque algunos de los programas más formales de formación de ingenieros y técnicos pueden proporcionar una introducción de alto nivel a los factores humanos, hay poca información disponible relacionada con la integración de los métodos de factores humanos en las tareas tradicionales de gestión de tecnología sanitaria.

Dado el papel único que los profesionales de la tecnología biomédica ya desempeñan en muchas organizaciones sanitarias y el valor demostrado que la aplicación de factores humanos a los sistemas sanitarios puede agregar, existe una oportunidad para que los profesionales de la tecnología biomédica asuman un papel más amplio. Estos profesionales

10

ayudan a cerrar la brecha entre las tecnologías y los usuarios y promover el uso seguro y eficaz de la tecnología, ambos complementarios a la filosofía de los factores humanos.

Esto no quiere decir que las organizaciones de salud no deben emplear a los profesionales de los factores humanos, sino que en ausencia de estos expertos, un profesional de la tecnología biomédica tiene muchas oportunidades para ampliar sus funciones y además de las diarias, aplicar métodos de factores humanos para mejorar la seguridad y la efectividad de las tecnologías de la salud.

11

Capítulo 2. Factores Humanos: Evolución de la Cabina de Mando a las Salas de Operación.

Sección 2.1 Introducción

Los factores humanos son una disciplina dedicada a aplicar lo que sabemos sobre las fortalezas y limitaciones de las personas a las tecnologías, procesos y entornos en los que vivimos y trabajamos para intentar hacer estos sistemas más seguros, más intuitivos y robustos. Dentro de la ciencia de los factores humanos, muchos expertos se centran en diseñar tecnologías para adaptarse a los atributos cognitivos y físicos de las personas, de modo que, en lugar de exigir que las personas se adapten al diseño de la tecnología, la tecnología se adapte para apoyar las capacidades de las personas. [9] Poniendo mecanismos de seguridad para detectar y corregir errores inevitables antes de que resulten en daño, las personas pueden ser ayudadas a completar sus tareas con seguridad y con éxito.

Esto puede sonar de sentido común, pero sorprendentemente, no es como tendemos a abordar el diseño de la tecnología en entornos de salud, o en nuestra vida cotidiana [10]. Todos cometemos errores; tiramos de una manija de la puerta que necesita ser empujada, olvidamos una contraseña para una cuenta importante, o llamamos a un miembro de la familia cuando quisiéramos telefonear a otro. Cuando cometemos errores, nuestra respuesta es por lo general descartar el error, atribuirlo a no prestar suficiente atención, o no tener cuidado suficiente. Sin embargo, considere por un momento los aspectos del diseño del dispositivo que influyeron en su comportamiento. La manija de la puerta parecía como si debiera ser tirada para abrir la puerta, o el gran número de contraseñas que tenemos hace que sea difícil recordarlas todas, o en el caso de las llamadas erróneas, los nombres de sus familiares estaban uno al lado del otro en su teléfono con pantalla táctil.

Cuando empezamos a mirar el mundo con una lente de factores humanos, podemos ir más allá de la reacción típica de culparnos por no ser cuidadosos o por no prestar suficiente atención, y en su lugar comenzar a reconocer oportunidades donde las mejoras en el diseño pueden disminuir los errores.

Por ejemplo, cuando podemos cambiar el diseño de la manija de la puerta para que intuitivamente sepamos que necesita ser empujada y no tirar de ella, no tenemos que preocuparnos de si estamos prestando atención o teniendo cuidado ese día porque el diseño de la manija de la puerta naturalmente nos anima a interactuar con ella correctamente.

Sección 2.2 Historia

La disciplina de los factores humanos surgió alrededor de la Segunda Guerra Mundial. En ese momento, la tecnología aeronáutica había avanzado significativamente, dando lugar a sistemas de control de vuelo más complejos. Aunque los pilotos estaban altamente capacitados, no se adaptaron fácilmente a estos nuevos sistemas de control, lo que resultó en un aumento de accidentes y la pérdida de muchos pilotos experimentados. [11] Los

12

psicólogos de la época se dieron cuenta de que el diseño de los sistemas de control de la cabina de pilotaje era confuso, incluso para los pilotos más experimentados, por lo que cuando los controles de la cabina fueron rediseñados para evitar esta confusión, casi todos los accidentes fueron eliminados como resultado.

Desde entonces, la ciencia de los factores humanos se ha aplicado a muchas otras industrias críticas de seguridad como el aeroespacial [12] y la energía nuclear, [13, 14] donde los fallos operacionales pueden resultar en pérdidas de vidas. La asistencia sanitaria, que también se considera una industria de seguridad crítica, ha sido comparativamente más lenta para adoptar la ciencia de los factores humanos [15]. Sin embargo, se ha logrado un progreso constante desde 1978, cuando los primeros médicos lo aplicaron para manejar los problemas de seguridad en la anestesia [16].

Sección 2.3 Por qué aplicar Factores Humanos a la atención de la Salud?

La importancia de aplicar los factores humanos para mejorar la seguridad del sistema en la asistencia sanitaria ha llegado a un punto de inflexión. Hay varias razones para ello, entre ellas varias publicaciones fundamentales [1, 17, 18] que ponen de relieve el grado en que la asistencia sanitaria es insuficiente como un sistema seguro. Desde el punto de vista de la tecnología sanitaria, algunos de los factores que contribuyen a este déficit incluyen el incremento en: 1) el número de tecnologías sanitarias presentes en las áreas de atención al paciente; 2) la complejidad de las tecnologías sanitarias; 3) el ritmo del cambio tecnológico.

(1) Número de tecnologías sanitarias presentes en las áreas de atención al paciente

Un aumento en el número de tecnologías de la salud presentes en las áreas de atención de los pacientes se suma a la carga mental del personal asistencial, que son responsables de operar y monitorear estos dispositivos. El impacto de este aumento de carga de trabajo mental, o carga cognitiva, en el rendimiento humano ha sido ampliamente estudiado, y la investigación indica que cuando la carga de trabajo mental es alta, los errores humanos ocurren con mayor probabilidad.[19] En la asistencia sanitaria, cuando la carga de trabajo mental excede las capacidades de las personas, los dispositivos pueden ser configurados incorrectamente, usados de manera inapropiada, o los indicadores de problemas pueden ser ignorados y los estudios han confirmado que esto tiene un impacto negativo en la seguridad del paciente. [20], [21]

(2) Complejidad de la tecnología sanitaria

La forma en que los seres humanos interactúan con los dispositivos está cambiando a medida que las tecnologías de salud se hacen cada vez más complejas. En el pasado, la tecnología estaba diseñada para que las funciones técnicas del dispositivo fueran controladas por el usuario, pero cada vez más a menudo, las interfaces de usuario están

13

diseñadas para mostrar sólo configuraciones y valores que el usuario debe observar o controlar. Como resultado, la capacitación que los usuarios reciben se enfoca más en cómo controlar los valores y configuraciones que en comprender los principios técnicos que rigen el funcionamiento del dispositivo.

Con el tiempo, esto tendrá el efecto de impedir que los usuarios desarrollen un modelo mental de cómo funciona un dispositivo. Esto es motivo de preocupación porque cuando surge una situación de crisis imprevista, los usuarios son incapaces de adaptar su interacción con la tecnología para manejar situaciones complicadas de manera apropiada. De hecho, sin una comprensión de los principios técnicos detrás de la operación de un dispositivo médico, una respuesta de los usuarios, aunque bien intencionada, puede hacer más daño que bien.

(3) El ritmo del cambio tecnológico

El ritmo acelerado de los cambios tecnológicos ha mejorado nuestra capacidad de brindar una atención más eficaz a pacientes más enfermos, pero nos ha desafiado a adaptar continuamente nuestras organizaciones de asistencia sanitaria para que apoyen adecuadamente estas tecnologías. Los cambios tecnológicos afectan en gran medida al personal de primera línea, que se ven obligados a aprender a utilizar nuevos dispositivos, a adaptar sus prácticas de trabajo y a mantener operaciones rutinarias de atención, a menudo sin una formación adecuada, o el apoyo de prácticas o políticas definidas que reflejen los cambios necesarios para responder a la nueva tecnología. Estas condiciones se han relacionado con el estrés laboral y el agotamiento del grupo de enfermería[22], y ambos se reconocen como aspectos críticos en la asistencia sanitaria.

Sección 2.4 Indicaciones observables que apuntan a problemas subyacentes de Factor Humano.

La aplicación de métodos y principios de factores humanos puede ayudar a identificar dónde y cuándo es probable que ocurran los problemas asociados con un desajuste entre usuarios, tecnologías y entornos. Como un profesional de la tecnología biomédica, hay una serie de pistas observables que pueden proporcionar una visión de aspectos subyacentes de factores humanos asociados con el uso de una tecnología en particular. Algunas de estas pistas incluyen situaciones cuando:

Nadie quiere usar el dispositivo o el sistema

Cuando los usuarios se niegan a usar o se apartan del camino para evitar el uso de una tecnología en particular, sugiere que la tecnología puede no: (1) ser intuitiva de usar, (2) realizar la función requerida, (3) encajar bien con el flujo de trabajo de los usuarios, o (4) haber sido presentada a los usuarios de una manera que proporcione familiaridad y capacitación adecuadas.

El dispositivo es enviado al servicio técnico, pero no se encuantra ningún problema

14

No encontrar ningún problema después de que se ha solicitado el servicio técnico, puede sugerir una tecnología mal diseñada [23], o una formación inadecuada, especialmente si la organización sanitaria ha implantado recientemente la tecnología.

Se están utilizando los accesorios incorrectos o los accesorios no están instalados correctamente

Cuando se utilizan accesorios incorrectos o los accesorios no se han instalado correctamente, a menudo es un signo de un diseño deficiente sin una coincidencia física clara entre el dispositivo y los componentes de conexión.

Las pantallas no son fáciles de leer

Si durante una inspección las pantallas de un dispositivo son difíciles de leer, es probable que dichas pantallas también sean difíciles de leer en condiciones clínicas, donde a veces existen condiciones de luz más oscuras y los usuarios están más alejados de los dispositivos.

Las funciones de alarma / alerta se han ajustado a valores erróneos

Durante una inspección, si los ajustes de alarma o alerta se han cambiado a valores que no tienen sentido para la intención de la alarma, es una pista que la alarma o configuración de alerta no son apropiados para el entorno clínico. En el caso de las alarmas, esto puede apuntar a un problema de diseño, o puede ser más un problema con cómo se han configurado los ajustes de alarma y si el personal entiende cómo configurar las alarmas.

Sección 2.5 Cómo pueden los Profesionales de la Tecnología Biomédica Ayudar a mejorar la Seguridad del Paciente.

Si se identifica alguna de estas pistas observables, los profesionales de la tecnología biomédica tienen la oportunidad de aplicar factores humanos para mejorar el uso efectivo de la tecnología y reducir el riesgo de errores de uso. Si bien la aplicación de los factores humanos ciertamente amplía las responsabilidades laborales existentes de un profesional de tecnología biomédica, con la práctica puede convertirse en una parte rutinaria del trabajo de gestión de la tecnología de la salud, teniendo un tremendo beneficio para el personal y los pacientes en las organizaciones de salud.

El siguiente caso de estudio ilustra cómo un profesional de la tecnología biomédica podría utilizar factores humanos en su trabajo cotidiano.

Caso de Estudio 1: Llegando al fondo de un problema sin fallo encontrado

Un desfibrilador llega a su departamento de ingeniería biomédica para su reparación con una nota grabada que dice "roto". Tras la inspección, no se puede encontrar ninguna avería. El desfibrilador se devuelve a la unidad, sólo para llegar de nuevo unos días más tarde con otra nota "roto" grabada. Lo inspeccionará nuevamente y el resultado será "sin fallo". Usted se pregunta por qué el personal de primera línea piensa que este dispositivo está roto cuando no hay nada técnicamente incorrecto con él. Tras la reflexión, usted sospecha que debe de haber algún tipo de problema con la forma en que se utiliza el dispositivo, pero no está exactamente seguro de cuál es el problema. Usted decide

15

que quiere saber más sobre lo que podría estar mal, así que se pone en contacto con el equipo de emergencia cardíaca para preguntar si puede observar la situación del código de emergencia desde una distancia segura, la próxima vez que vaya a atender a un paciente. De esta manera usted puede ver el desfibrilador en uso para ver si el personal se topa con cualquier problema.

Usted oye una llamada de código azul (código de parada cardíaca) y un poco más tarde acompaña al equipo de atención cardíaca al laboratorio de cateterización. A medida que observa, ve al responsable activar el desfibrilador, pero por alguna razón, este no descarga. El clínico deja el desfibrilador a un lado y encuentra un segundo desfibrilador. Cuando el responsable activa este desfibrilador, se descarga como se esperaba y es capaz de restaurar el ritmo cardíaco normal del paciente.

Una vez finalizada la respuesta al paro cardíaco, el desfibrilador que funciona mal se devuelve a su base de cargador en el carro de choque. Usted inspecciona el desfibrilador que funciona mal y nota que la luz de estado de la batería no está encendida, lo que significa que la batería no se está cargando. A medida que echa un vistazo más de cerca, se da cuenta de que el desfibrilador no está totalmente conectado con el cargador. Intenta presionar el desfibrilador y ve que tiene que presionar con fuerza antes de oír un clic y ver que la luz de estado de la batería se ilumina. Problema identificado - las baterías del desfibrilador no se estaban cargando porque el chasis no estaba completamente articulado con el cargador.

Ahora que ha identificado el problema, ¿qué debe hacer al respecto? Usted podría simplemente decirle al personal que cuando colocan el desfibrilador en el cargador tienen que recordar empujar hacia abajo con fuerza hasta que escuchen un clic pero, dadas nuestras limitaciones en la memoria y la atención, las posibilidades de que el personal siempre recuerde hacer esto son bajas. Se sabe que las situaciones de paro cardiaco se asocian con una alta carga de trabajo cognitivo, lo que significa que el personal está operando típicamente en los límites de la memoria y la atención, y están bajo mucho estrés. Una solución óptima es comprar desfibriladores que se pueden conectar fácilmente al cargador. Sin embargo, esto no suele ser una opción hasta el final del ciclo de vida de la tecnología, cuando la organización de atención médica compra nuevos dispositivos. En el ínterin, una estrategia para minimizar la probabilidad y aumentar la detectabilidad de que el desfibrilador no está debidamente conectado al cargador es desarrollar una lista de verificación de preparación para quien sea responsable de volver a surtir y organizar el carro de emergencia, después de el código azul, e incluir una inspección del estado de carga de la batería del desfibrilador en la lista de verificación. La lista de verificación debe adjuntarse al carro de emergencia para la referencia fácil.

Como profesional de la tecnología biomédica, si no hubiera salido al campo para observar el desfibrilador en uso, probablemente habría sido devuelto a su departamento muchas más veces con el mismo signo "roto" en él. Observar cómo interactúan las personas con la tecnología puede ser un ejercicio extremadamente valioso y fructífero.

Aún más valioso es la aplicación de métodos similares de factores humanos durante la adquisición para ayudarle a identificar estos tipos de desafíos antes de que se seleccione un dispositivo.

Cuando se identifican problemas como este durante la adquisición, se puede seleccionar un dispositivo diferente para evitar el problema en su totalidad, o las soluciones se pueden identificar e implementar antes de la implementación del dispositivo.

Caso de Estudio 1: Llegando al fondo de un problema sin fall o encontrado

16

Capítulo 3. Pensando en Factores Humanos

Tener una apreciación de la importancia de los factores humanos, y una comprensión básica de las fortalezas y limitaciones que compartimos como seres humanos, puede ayudar a entender cómo pensamos acerca de la relación entre seres humanos y las tecnologías. Las tecnologías deben ser diseñadas y elegidas para complementar nuestras habilidades naturales, apoyándonos en las cosas que nos son inherentemente más difíciles de hacer. Así como las propiedades eléctricas y mecánicas de las tecnologías están limitadas por las leyes de la física, el rendimiento humano también está limitado por principios conocidos de rendimiento cognitivo y físico. Cuando se ignoran estas restricciones, pueden producirse fallos de los sistemas.

Este capítulo ofrecerá un telón de fondo de perspectivas y marcos de factores humanos para apoyar los métodos y aplicaciones descritos en el resto del libro.

Sección 3.1. La división mecanicista-humanista

En su libro “El Factor Humano” [9], Kim Vicente describe que como sociedad, hemos tendido a aprender sobre nuestro mundo utilizando un enfoque reduccionista, mediante el cual una mentalidad de "divide y conquista" permite a la gente tener un profundo entendimiento sobre un tema en particular. Esto es generalmente útil porque somos capaces de aprender mucho sobre un fenómeno específico, sin embargo, puede llegar a ser problemático por los muchos silos dispares de información que se crean en el proceso. Como resultado de este enfoque en silos, históricamente ha habido una división entre las ciencias humanas (por ejemplo, la psicología cognitiva) y las ciencias técnicas (por ejemplo, la programación e ingeniería de computación), en la que los Humanistas tienen una buena comprensión de cómo piensa la gente, y los Mecanicistas tienen una buena comprensión de cómo hacer que la tecnología funcione.

Los factores humanos sirven para cerrar la brecha entre los humanistas y los mecanicistas, reuniendo una comprensión de la conducta humana natural - cómo piensa la gente, nuestras fortalezas y limitaciones físicas y cognitivas - y cómo hacer que la tecnología funcione, para que las tecnologías puedan apoyar mejor cómo las personas tienden a pensar y actuar. En el mundo real, las personas no existen sin tecnología, y la tecnología no existe sin personaspor lo que es importante considerar lo que sucede en la interfaz de estas dos entidades.

Esta visión de sistemas es un principio fundamental de la ciencia de los factores humanos y está en el corazón de todo método de factores humanos que se explorará en este libro.

17

Sección 3.2. La escala humano-técnica

La aplicación de factores humanos requiere una comprensión de las necesidades de todas las personas en el sistema y la interacción entre ellos. La Escalera Humano-Técnica de Vicente [9] (Figura 2) es útil para visualizar la relación que las personas de un sistema tienen con las tecnologías desde una serie de perspectivas. Las siguientes descripciones de cada peldaño de la escala Humano-Técnica han sido adaptadas del Programa de Educación para la Seguridad del Paciente (PSEP) del Instituto Canadiense de Seguridad del Paciente.

El peldaño Físico de la Escala Humano-Técnica nos permite pensar en cómo los seres humanos interactúan con las tecnologías a nivel físico. Cuando algo es demasiado pesado para ser levantado o está demasiado lejos para ser fácilmente alcanzado, hay un claro desajuste entre cómo la tecnología fue diseñada y los usuarios finales previstos.

El peldaño Psicológico nos permite considerar el encaje cognitivo entre humanos y tecnologías. Si una tecnología requiere más capacidad cognitiva de un usuario de la que está disponible durante una tarea (por ejemplo, recordar una larga serie de números), o es contra-intuitiva a como la gente podría esperar interactuar con un dispositivo similar, resultará un desajuste entre el diseño de la tecnología y el usuario.

El peldaño del Equipo nos hace pensar en cómo las tecnologías deben considerar la comunicación entre múltiples personas en el sistema y facilitar la dinámica de los equipos Las tecnologías deben diseñarse para permitir que varias personas trabajen hacia un resultado común.

18

Figura 2. Escalera Humano-Técnica de Vicente [CPSI PSEP]

El peldaño Organizacional asegura que consideramos que las tecnologías también deben encajar bien con las características del trabajo, tales como la cultura organizacional, los horarios, los incentivos y los desincentivos.

Por último, el peldaño Político destaca que las tecnologías también deben encajar bien con las personas en el plano político. Este nivel incorpora atributos tales como presupuestos, leyes, reglamentos y opinión pública.

Sección 3.3. Introducción a la Ingeniería Cognitiva

Al pensar en el ajuste entre los seres humanos y las tecnologías, un buen punto de partida está en los dos peldaños inferiores de la Escala Humana-Técnica (es decir, el ajuste físico y psicológico).

El ajuste físico entre una persona y una tecnología por lo general se puede observar directamente, por ejemplo, un dispositivo puede ser demasiado pesado para que alguien lo

19

levante. Por el contrario, el ajuste psicológico o cognitivo entre una persona y una tecnología puede ser mucho más difícil de discernir. La forma en que las personas perciben, procesan y reaccionan a la información está influenciada por varios factores, incluyendo la capacidad cognitiva (es decir, limitaciones y sesgos) y otros factores externos que están sucediendo a nuestro alrededor.

En general, los seres humanos son muy buenos en tareas cognitivas como encontrar e interpretar patrones, pero luchamos con cosas como la aritmética mental y recordar listas de información. Aunque podemos realizar estas tareas cognitivas más difíciles, somos mucho más propensos a cometer errores en estos casos. La aplicación de estos conocimientos al análisis de las tareas necesarias para el uso de la tecnología sanitaria puede permitir identificar y rediseñar las tareas propensas a errores, o bien añadir mecanismos de apoyo a la seguridad. Las capacidades cognitivas y las limitaciones descritas en este capítulo se incluyen para ayudarle a notar y considerarlas al conducir los métodos de factores humanos presentados en la Parte III.

Sección 3.3.1. Habilidad cognitiva

Como seres humanos, tenemos limitaciones naturales cuando se trata de nuestras habilidades cognitivas incluyendo limitaciones en la memoria, la atención y sesgo cognitivo. Cuando las tareas requieren capacidades cognitivas mayores que las que tenemos, o nos presionan de manera que invocan nuestros sesgos cognitivos, no nos damos cuenta de cosas, olvidamos cosas o tomamos decisiones sub-óptimas.

Sección 3.3.1.1 Memoria

Nuestra memoria es donde se almacena la información que se recoge del campo. Hay dos tipos principales de memoria: trabajo, o memoria a corto plazo; y la memoria a largo plazo.

La información temporal se almacena en nuestra memoria de trabajo y usamos esta forma de memoria para procesar la información examinando, evaluando, transformando y comparando diferentes representaciones mentales de esa información. La capacidad de nuestra memoria de trabajo es limitada y cuando nuestra atención es atraída a otra parte, puede ser especialmente vulnerable. A menudo nos basamos en nuestra memoria de trabajo sin ni siquiera darnos cuenta, lo cual puede ser problemático dado el número de cosas que tenemos que recordar y las muchas distracciones, interrupciones y tareas que suceden a la vez.

Los hechos sobre el mundo y los modelos mentales de cómo hacer las cosas tienden a ser almacenados en nuestra memoria a largo plazo. Inicialmente, la información se almacena en nuestra memoria de trabajo y a través de la repetición y el entrenamiento, parte de esta información se transfiere a nuestra memoria a largo plazo donde podemos recordarla o reconocerla según sea necesario. Cuando no podemos recuperar o reconocer la información, puede ser problemático, lo que provoca errores o aumenta el tiempo para completar una tarea.

20

Sección 3.3.1.2 Atención

En nuestra vida cotidiana somos bombardeados con información, pero no en todo podemos prestar atención en cualquier momento. La atención es el proceso que utilizamos para seleccionar la información a la que atendemos y respondemos en cualquier momento. Es lo que mejora e inhibe la información en cualquier momento, dadas nuestras intenciones. [24]

Aunque tenemos una variedad de mecanismos para ayudarnos a seleccionar, enfocar y mantener nuestra atención, nuestra capacidad total de atención es limitada. Cuando tratamos de prestar atención a algo que requiere más capacidad de atención que la que queda, automáticamente dejamos de atender a otra cosa para liberar los recursos necesarios. Esto conduce a la ceguera no intencional, cuando no nos damos cuenta de cosas que son importantes y pueden parecer obvias para los demás, o que pueden parecer obvias después del hecho, porque nuestra atención está enfocada en otra parte. [25] Un buen ejemplo de esto es no darse cuenta de lo cerca que está un coche delante de usted hasta después de haberlo golpeado porque su atención estaba en otra cosa, como la radio o el teléfono.

Sección 3.3.1.3 Sesgos cognitivos

Los seres humanos están construidos para ver el mundo de acuerdo con una serie de sesgos cognitivos. Los sesgos cognitivos se adquieren como resultado de nuestra tendencia a usar heurísticas, o reglas básicas, al procesar la información como un medio para disminuir la carga de trabajo cognoscitiva en nuestros cerebros. Aunque son útiles para producir atajos para la toma de decisiones al reducir la carga de trabajo cognoscitiva, estos sesgos aumentan la probabilidad de sacar conclusiones incorrectas sobre la información e introducir errores en nuestros procesos de pensamiento. Hay muchos sesgos cognitivos conocidos, y algunos ejemplos se describen con más detalle a continuación.

Sesgo de confirmación

Un sesgo de confirmación es la tendencia de las personas a buscar o interpretar información que confirme una noción preconcebida. Ves lo que esperas ver, no lo que realmente está allí.

Pensamiento en grupo

Pensar en equipo es la tendencia de un grupo con intereses similares a llegar a un consenso, incluso si no hay evidencia disponible para apoyar ese consenso, para minimizar el conflicto dentro del grupo.

Sesgo de omisión

Un sesgo de omisión es la tendencia de los seres humanos a creer que una acción dañina es peor, o menos moral, que una ausencia de acción igualmente perjudicial.

Efecto de encuadre

21

El efecto de encuadre describe la tendencia de las personas a sacar conclusiones diferentes del mismo conjunto de información dependiendo de cómo se presenta esa información.

Sesgo de proximidad

Un sesgo de proximidad es una tendencia de las personas a dar mayor importancia a algo que se ha observado o experimentado recientemente.

Para una lista más completa de sesgos cognitivos, vea la entrada de Wikipedia para

Sesgos Cognitivos (https://es.wikipedia.org/wiki/Sesgo_cognitivo).

Sección 3.3.2. Factores externos que afectan la capacidad cognitiva

Además de los factores antes mencionados que afectan la capacidad cognitiva, existen varios factores externos que influyen en la precisión y efectividad con la que podemos procesar la información, incluida la carga de trabajo, la vigilancia y la fatiga. Estos factores deben ser considerados al evaluar la adecuación entre los recursos cognitivos necesarios para completar las tareas utilizando la tecnología y los recursos cognitivos disponibles para completar esa tarea.

Sección 3.4. Modelo de queso suizo de Reason para la causa de accidentes

Cuando somos desafiados más allá de nuestras limitaciones humanas físicas o psicológicas, es más probable que ocurran errores. En un intento de evitar que los errores lleven a un fallo del sistema, muchos sistemas críticos de seguridad incorporan barreras para tratar de detectar y evitar que los errores lleven finalmente a incidentes. Para considerar cómo los errores pueden propagarse de las decisiones y acciones hechas en el flujo de actividades hasta el paciente, se puede usar el Modelo de queso suizo de Reason (Reason, 2000) (adaptación mostrada en la Figura 3).

Este modelo muestra que en la asistencia sanitaria, incluso cuando existen varias barreras para evitar que los errores lleguen a los pacientes, cada barrera, por muy bien pensada o bien intencionada, tiene debilidades inherentes. Estas debilidades, que están en constante movimiento, finalmente se alinearán para crear oportunidades para que los peligros se propaguen a través del sistema y se conviertan en eventos adversos. Estas debilidades pueden provenir de una serie de fuentes a lo largo de los peldaños de la escala de Humana-técnica incluyendo niveles físico y psicológico, como se señaló anteriormente, sino también el equipo, la organización y los niveles políticos.

22

Figura 3. Adaptación del modelo de queso suizo de Reason

En el modelo de Reason (Figura 3), las rebanadas de queso representan las barreras establecidas para tratar de hacer nuestro sistema de salud más seguro. Dentro de cada barrera bien intencionada, existen una serie de debilidades, representadas por los agujeros en el queso. Es importante tener en cuenta que los orificios o debilidades inherentes a cada barrera no son estáticos, por lo que las condiciones en el sistema siempre están cambiando. Cuando un agujero en una rebanada se alinea con queso en la siguiente, el error es atrapado o mitigado. Sin embargo, cuando un agujero en una barrera se alinea con un agujero en el siguiente, y así sucesivamente, los peligros tienen la oportunidad de deslizarse a través de las barreras que se han puesto en su lugar, y encontrar su camino al paciente.

Sección 3.4.1. Fallos activos

Los agujeros en el extremo del sistema que entran en contacto con el paciente se llaman fallos activos, típicamente involucrando personal a la cabecera como enfermeras, médicos, etc. La mayoría de los análisis de errores tienden a identificar solamente las fallos activos, lo que resulta en la asignación de la culpa a los responsables de los fallos activos. Estos fallos activos son el resultado de diferentes mecanismos que incluyen deslices, lapsos, o errores o violaciones.

23

Sección 3.4.1.1 Desliz

Un desliz ocurre cuando la información percibida es interpretada correctamente, y se piensa la respuesta correcta pero se realiza la acción incorrecta accidentalmente. Un ejemplo es saber un número de teléfono pero presionar una tecla incorrecta en el teléfono al marcar.

Sección 3.4.1.2 Lapso

Un lapso se produce cuando las acciones previstas son correctas, pero hay un lapso temporal de memoria o atención. Un ejemplo es presionar un bolígrafo en el papel para escribir algo, pero olvidando hacer clic en el extremo del lápiz para extenderlo primero.

Sección 3.4.1.3 Error

Un error se produce cuando la información no se interpreta correctamente, lo que conduce a una acción incorrecta. Por lo general ocurren cuando malinterpreta una situación o aplica incorrectamente una regla. Un ejemplo es el establecimiento de su alarma para las 6:30 pm cuando se pretende establecer para 6:30 am.

Sección 3.4.1.4 Violación

Una violación ocurre cuando se hace una elección para actuar en contra del protocolo aceptado. Una violación puede ser bien intencionada cuando alguien identifica que las reglas no son propensas a conducir al resultado apropiado. Un ejemplo es un piloto que opta por ignorar las advertencias del Control de Tráfico Aéreo porque saben que otro avión que está en un camino de colisión ya ha cambiado de rumbo.

Incluso cuando un error se identifica como un desliz, un lapso o un error, a veces es difícil para las organizaciones identificarlo como un error del sistema, particularmente si hay una historia fuerte o cultura de culpar en la organización. Para facilitar la identificación de fallos del sistema cuando ocurren, el Árbol de Decisión de Incidentes para Responder a Eventos de Seguridad del Paciente [26] proporcionado en la Parte III puede usarse como una guía para evaluar la culpabilidad.

Sección 3.4.2. Fallos latentes

Los agujeros que están arriba y en el centro del sistema, que no entran en contacto directo con el paciente se llaman fallos latentes. Estas debilidades típicamente resultan de diseños y decisiones que se hacen más adelante en el sistema, tales como decisiones sobre qué tecnología comprar, capacitación, programación, presupuestos, niveles de personal y políticas. La presencia de fallos latentes en un incidente destaca que hay factores de sistemas que contribuyen al incidente.

Sección 3.5. Jerarquía de la Efectividad

Cuando se aplican los métodos de factores humanos a problemas de seguridad de la tecnología de la salud, no es suficiente solo identificar aspectos de factores humanos. Una vez que se ha identificado un problema, es necesario desarrollar una estrategia de mitigación para evitar que tal problema cause daño a los pacientes y/o al personal. Sin embargo, no todas las soluciones atenuantes se crean igualmente. Desafortunadamente, una estrategia

24

que se ve bien en papel en términos de recursos requeridos y facilidad de implementación no siempre tiene el efecto positivo esperado una vez implementado. La solución no puede abordar la causa raíz del problema o puede depender de que los usuarios realicen trabajos adicionales, lo que suele conducir a un cumplimiento deficiente en el tiempo o a problemas nuevos e imprevistos derivados de la carga de trabajo adicional.

La jerarquía de la efectividad [26] (Figura 4) es un marco que le ayudará a considerar la efectividad probable de diferentes estrategias de mitigación. Es un marco informado de factores humanos que puede utilizarse para considerar la efectividad de un diseño o la estrategia de mitigación de errores, en función del grado en que la solución está incrustada en el sistema versus que dependa de los cambios de comportamiento de las personas.

Figura 4. Jerarquía de Efectividad (adaptado de ISMP)

La jerarquía de la efectividad va desde las estrategias centradas en la persona en la parte inferior hasta las estrategias centradas en el sistema en la parte superior. A medida que las estrategias van desde la persona hasta el sistema, generalmente se vuelven más efectivas como lo indica la flecha verde de la Figura 4. Sin embargo, tenga en cuenta que lo más importante es adaptar la solución al problema que resolver un problema con estrategias de los niveles más altos de la jerarquía. Si bien las estrategias centradas en la persona para prevenir errores son más fáciles de identificar e implementar, estos tipos de estrategias dependen de la vigilancia, y así, incluso cuando las personas tienen las mejores intenciones, la presión de la eficiencia en el trabajo conducirá eventualmente a la decadencia de estas estrategias y la gente volverá a realizar su trabajo tan eficientemente como sea posible, sin importar cómo se espera que se haga. Esto es especialmente cierto en la asistencia sanitaria, donde los médicos quieren ayudar a los pacientes lo mejor que pueden y están a menudo sobrecargados de tareas y responsabilidades. En contraste, más estrategias centradas en los

25

sistemas se centran en elementos cambiantes del propio sistema para eliminar todos los peligros potenciales. Es por eso que las estrategias centradas en el sistema suelen ser más robustas que las estrategias centradas en las personas; ellas apoyan las decisiones y acciones de las personas y minimizan el requisito poco realista de que la gente piense, se comporte y actúe perfectamente. Las estrategias representadas en cada uno de los niveles de la jerarquía se describen aquí:

Educación e Información

Según la jerarquía de efectividad, la educación e información es la estrategia menos eficaz para reducir los errores. A pesar de que la capacitación se utiliza a menudo para familiarizar a las personas con las nuevas tecnologías y sistemas, y es una excelente manera de practicar las habilidades necesarias para llevar a cabo con seguridad un trabajo, no es muy eficaz cuando se aplica como respuesta a una pobre tecnología o diseño de sistema, o para reforzar el uso adecuado de una tecnología. La capacitación que pretende mitigar una pobre tecnología o diseño del sistema, hace que estar vigilante sea la responsabilidad del usuario. Por ejemplo, incluso si un usuario estuviera capacitado acerca de cómo superar una característica problemática del dispositivo, todavía sería posible que el usuario cometiera un error, dependiendo de las otras presiones cognitivas y de trabajo que experimente en ese momento.

Normas y Políticas

Las normas y políticas se implementan a menudo en las organizaciones sanitarias porque pueden ser ampliamente difundidas y guiar al personal en la conducta apropiada en el lugar de trabajo. Las reglas y las políticas se ponen a menudo como resultado de un incidente para controlar cómo la gente se comporta y actúa, pero no siempre impiden que se realice una acción y no llega al nivel de factores del sistema que contribuyeron a un incidente. Dependiendo de las exigencias impuestas a un miembro del personal, las reglas no siempre son seguidas o seguidas correctamente, especialmente si el personal no está familiarizado, o si no creen que las reglas y políticas encajan, o aplican en una situación dada.

Recordatorios, listas de comprobación, comprobaciones dobles

Recordatorios, listas de verificación y dobles comprobaciones pueden reducir los errores al ayudar a la gente a recordar y al involucrar a varias personas en un proceso. Sin embargo, aunque estas herramientas pueden parecer útiles, con el tiempo pueden perder capacidad de deteción cuando la lista de verificación o el recordatorio se aplican rutinariamente. A menudo, cuando se realizan dos verificaciones, no se realizan de manera autónoma, e incluso cuando están, todavía son susceptibles a sesgos cognitivos comunes como sesgo de confirmación. No es raro que más de una persona cometa el mismo error. Recordatorios, listas de verificación y doble verificación pueden ayudar a identificar errores, o recordarnos que buscar errores, sin embargo, no previene que ocurran errores.

Simplificación y estandarización

La simplificación y la estandarización tienden hacia una estrategia más centrada en el sistema para prevenir errores porque estos tipos de soluciones adaptan los sistemas para

26

que coincidan con lo que la gente espera y reducen el número de opciones y complejidad presentadas, lo que ayuda a las personas a concentrarse en las partes importantes de una tarea, en vez de tratar de buscar el camino a través de una colección de información. Aunque la simplificación y la estandarización pueden ayudar a prevenir los errores, no es una panacea porque las personas siguen propensas a cometer errores, y este tipo de soluciones solo abordarán algunos de los problemas dentro de un sistema.

Automatización e Informatización

La automatización y la informatización tienden a ser el segundo tipo de solución más eficaz, porque algunas de las tareas que sabemos que son potencialmente problemáticas para las personas se pueden trasladar a los computadores. Aquellas tareas en las que los seres humanos no son muy buenos, como memorizar, calcular o monitorear una situación de cambios, pueden transferirse a sistemas informáticos, que son mucho más confiables para realizar este tipo de actividades. Aunque la automatización puede ser un medio fiable de apoyar las capacidades de las personas, todavía es posible que se introduzcan errores cuando un sistema ha sido automatizado o informatizado. Dado que los sistemas automatizados y computarizados son diseñados y monitoreados por los seres humanos, los errores podrían ser introducidos en cualquier interfaz entre las personas y el sistema automatizado.

Forzar Funciones y Restricciones

De acuerdo con la jerarquía de efectividad, forzar funciones y restricciones es el tipo de solución más eficaz. Forzar funciones y restricciones son características de diseño que fuerzan o impiden que un usuario lleve a cabo una acción que podría conducir a un error. Se consideran el método más robusto de prevenir errores porque al impedir que la gente continúe por el camino de un error, es poco probable que el error sea realmente ocurrir. Aunque forzar funciones se considera el tipo más robusto de soluciones, a menudo puede resultar difícil incorporar soluciones verdaderas de funciones forzadas en la tecnología, proceso o sistema que se está mejorando. Además, en la asistencia sanitaria puede ser necesario incluir una función de "anulación" en algunos casos, lo que puede alentar al personal a evadir las funciones forzadas por completo. Un ejemplo de una función forzada sería el conector de línea de gas que codifica las máquinas de anestesia. Las boquillas para cada línea de gas están diseñadas para encajar sólo en el zócalo correspondiente (Sistema de seguridad por índice de diámetro).

27

Parte II Manual de Métodos de Factores Humanos

Los métodos de factores humanos son variados y flexibles en su aplicación. A menudo se parecen a las tareas que uno haría naturalmente como parte de un análisis de tecnologías de la salud y problemas de tecnología de la salud. Sin embargo, cada método tiene principios básicos y fundamentos que deben aplicarse conscientemente para asegurar que el análisis sea objetivo y los resultados sean válidos, de modo que se realicen los beneficios de los métodos.

La Parte II detallará cómo emprender cada una de las nueve técnicas y métodos de factores humanos seleccionados para apoyar el uso seguro y eficaz de la tecnología de la salud por parte de los profesionales de la salud. Estos métodos son los siguientes:

Recopilación de Datos para Entender a los Usuarios y el Entorno de Uso

Observaciones

Entrevistas, grupos focales y encuestas

Análisis de tareas

Métodos de Evaluación de Factores Humanos

Análisis heurístico

Pruebas de usabilidad

Métodos de Factores Humanos de Análisis de Riesgos e Incidentes

Análisis de Factores Humanos de Modo Informado de Fallos y Efectos (HFFMEA)

Análisis de Factores Humanos de Causa Raíz (HFRCA)

Métodos de Factores Humanos de Adquisiciones Informadas

Proceso de Factores Humanos de Adquisición e Implementación informada (HFPIP)

Una vez que estos métodos de factores humanos han sido dominados, el profesional de la tecnología biomédica será capaz de entender: las necesidades de los usuarios con respecto a tecnologías específicas; el entorno de uso y los factores ambientales que influyen en el desempeño del usuario; cómo evaluar la tecnología para identificar problemas de diseño que puedan conducir a errores humanos; cómo evaluar objetivamente el desempeño del usuario y determinar su impacto en la seguridad del paciente; y cómo investigar los problemas tecnológicos que podrían, o ya han conducido, al daño del paciente.

28

Recopilación de Datos para Comprender a los Usuarios y el Entorno de Uso

Un ambiente típico de cuidados intensivos que requiere los esfuerzos coordinados de muchas personas y tecnología.

29

Capítulo 4. Observación

Sección 4.1. Preparando el escenario

Cuando las personas con formación y experiencia similares se enfrentan a una situación particular, no es raro encontrar que adoptan enfoques bastante diferentes para manejar la situación. Esto no es necesariamente porque una persona tiene un enfoque mejor o más información que otra, sino porque hay muchos factores que influyen en cómo las personas realizan su trabajo. En la atención de la salud, creemos que las personas desean hacer su trabajo de manera segura y eficaz, y que cuando su desempeño es inseguro o ineficaz, hay factores que influyen en su desempeño y de los cuales pueden o no ser conscientes.

Estos factores provienen de una combinación de causas internas y externas que pueden variar con el tiempo. Ejemplos de factores externos que pueden afectar el trabajo incluyen el diseño del equipo, la disposición física de un espacio de trabajo, el flujo de trabajo esperado y las prácticas de trabajo, las políticas organizacionales, la dinámica de equipo y la cultura organizacional. Factores internos o limitaciones humanas naturales (Capítulo 3), que pueden afectar nuestro trabajo incluyen nuestra capacidad de recordar múltiples unidades de información, o prestar atención a muchas cosas que están sucediendo al mismo tiempo. La gente también varía en términos de su nivel de habilidad y capacidad para realizar ciertas tareas basadas en factores como edad, nivel de entrenamiento y experiencia.

Observar a las personas a medida que interactúan con tecnologías, entornos y entre sí nos brinda una ventana hacia cómo las personas hacen las cosas. Al ver los factores que configuran la manera en que el personal aborda su trabajo, nos da una idea de los problemas existentes y posibles áreas de desajuste entre las personas y los sistemas de los que forman parte.

Sección 4.2. ¿Qué son las Observaciones?

Las Observaciones, a veces denominadas etnografía o sombra, son una técnica de recopilación de datos en la que un especialista en factores humanos mira, u observa a las personas que desempeñan sus tareas cotidianas en su entorno de trabajo normal. Se puede utilizar una variedad de herramientas de recopilación de datos para recopilar datos estructurados o no estructurados mientras se observa. Ejemplos de estas herramientas incluyen toma de notas, fotografías, software de análisis de tareas, colección de artefactos y, a veces, grabación de video.

Sección 4.3. ¿Por qué Utilizar Observaciones?

La realización de observaciones es un medio relativamente barato y valioso para recopilar información clave sobre los usuarios mientras realizan tareas en su entorno de trabajo. A través de las observaciones, puede saber qué usuarios clínicos están interactuando

30

con un dispositivo, qué tareas se están realizando, qué otros aspectos del entorno son relevantes para usar un dispositivo y ver los desafíos reales, las soluciones y las estrategias que están sucediendo en tiempo real. Las observaciones proporcionan un contexto esencial para definir los ámbitos del problema, y a menudo orientan a los practicantes de factores humanos caminos inesperados de descubrimiento, que terminan siendo clave para el problema en cuestión.

Los datos de observación tienden a ser complementarios a otros datos cualitativos como entrevistas, grupos focales o datos de encuestas. Por lo tanto, las entrevistas, los grupos focales y las encuestas no deben utilizarse en lugar de las observaciones. Las observaciones son esenciales para comprender cómo suceden las cosas, mientras que las entrevistas, los grupos de enfoque y las encuestas son más útiles para comprender mejor por qué suceden desde la perspectiva de un sujeto.

Es importante observar antes que preguntar a un sujeto cómo sucede algo, porque es común que las personas perciban procesos paso a paso de manera diferente de lo que ocurre en la realidad. Esto se debe a las limitaciones humanas inherentes como sesgos cognitivos (Sección 3.4) (por ejemplo, sesgo de confirmación, sesgo por falta de atención, pensamiento en grupo), y porque las personas no tienden a pensar en procesos bien conocidos en pasos discretos. A través de observaciones, el especialista en factores humanos puede identificar las brechas entre las acciones percibidas y los eventos reales en un nivel apropiado de detalle.

Desde la perspectiva de los profesionales de la tecnología biomédica, realizar observaciones será útil para:

• Identificar los diferentes grupos de usuarios de un dispositivo

• Comprender qué debe hacer un dispositivo para soportar las tareas de los usuarios

• Comprender cómo interactúan actualmente los usuarios con un dispositivo

• Comprender cómo se ajusta un dispositivo dentro del sistema más amplio (por ejemplo, cómo se integra con los sistemas de información existentes, listas de verificación o protocolos y políticas relacionados)

• Identificar retos y riesgos con un dispositivo ya en uso

• Determinar los diferentes niveles de conocimiento entre los usuarios y que tan bien los usuarios entienden el funcionamiento del dispositivo

Sección 4.4. Cuándo usar Observaciones

Las observaciones deben realizarse siempre que el profesional de los factores humanos no esté seguro de cómo o por qué sucede algo en el campo. Las observaciones deben considerarse como el método "de arranque", ya que casi siempre, será el punto de partida para cualquier análisis de factores humanos. Dado que los datos de observación son complementarios a los datos recopilados utilizando otras técnicas de recopilación de datos

31

cualitativos, las observaciones deben realizarse siempre que se hayan realizado entrevistas, grupos focales o encuestas.

Sección 4.5. Preparación para la Recopilación de Datos en la Observación

Sección 4.5.1. Cómo estructurar la recopilación de datos

Decidir si utilizar un enfoque estructurado o exploratorio para la recolección de datos dependerá de lo que usted, el observador, ya sabe acerca de los usuarios, dispositivos, procesos y entornos de interés. Cuando ya se ha logrado un entendimiento detallado, puede utilizarse un enfoque más estructurado para la recopilación de datos; sin embargo, si se sabe poco, se debe adoptar un enfoque exploratorio de recolección de datos. La Figura 5 proporciona algunas orientaciones sobre si se debe tomar un enfoque de recolección de datos estructurado o exploratorio basado en lo que usted ya sabe acerca de los usuarios, dispositivos, procesos y entornos de interés.

Figura 5. Consideraciones para un enfoque estructurado versus no estructurado de la recolección de datos

32

Sección 4.5.1.1 Recopilación exploratoria de datos

Cuando se toma un enfoque exploratorio de la recopilación de datos, significa que las observaciones están dirigidas a desarrollar una comprensión general de los factores que influirán en cómo se utiliza una tecnología y si se utilizará con éxito. Comienza con una comprensión de quiénes son los usuarios, qué tareas realizan y posibles problemas relacionados con el uso de una tecnología en particular. Un enfoque estructurado para la recopilación de datos suele seguir observaciones exploratorias porque se necesita una comprensión básica detallada del sistema de interés para poder desarrollar herramientas apropiadas de recopilación de datos (por ejemplo, listas de verificación de tareas/flujos de trabajo) para apoyar el objetivo de las observaciones estructuradas. Al tomar un enfoque exploratorio, una herramienta formal de recopilación de datos no se utiliza normalmente. En su lugar, las notas y fotografías de lo que está viendo deben registrarse en tiempo real, o inmediatamente después de una sesión de observación.

Mientras realiza observaciones exploratorias, tome nota de cosas como:

¿Qué tecnologías se están utilizando?

¿Cuándo, por qué y cómo se utilizan las tecnologías?

¿Cuáles son las condiciones ambientales en las que se están utilizando las

tecnologías (ruido, iluminación)?

¿Cuáles son las configuraciones de espacio del entorno de trabajo?

¿Qué procesos se están llevando a cabo?

¿Qué información (por ejemplo, formularios, gráficos, interfaces electrónicas o

políticas) se está utilizando?

¿Qué conocimiento, habilidades, capacitación o educación está accesando juntas

el usuario?

¿Cuáles son los objetivos del usuario?

¿Qué problemas, retos, soluciones o estrategias se están utilizando?

¿Cuáles son las entradas y salidas de lo que está observando?

¿Cómo trabajan las personas en relación con el dispositivo?

Sección 4.5.1.2 Recopilación estructurada de datos

Cuando se selecciona un enfoque estructurado para la recolección de datos durante las observaciones, los usuarios son observados con un conjunto específico de preguntas en mente, por ejemplo, qué tareas realizan las enfermeras con un monitor de telemetría en particular y dónde realizan esas tareas.? Al tomar un enfoque estructurado, se utiliza normalmente una herramienta de recolección de datos para rastrear los datos de observación en contra de un conjunto específico de preguntas. El propósito de una herramienta de recolección de datos es asegurar que cada observador está capturando la misma información durante cada sesión de observación. La herramienta de recopilación de datos que usted elija puede variar, pero generalmente, una simple herramienta de papel con

33

espacio dedicado para cada información requerida será suficiente. El recolector de datos suele diseñar la herramienta de recolección de datos basándose en lo que esperan observar y los objetivos de las sesiones de observación. Normalmente, se requerirán observaciones preliminares para determinar qué elementos de datos desea capturar en un formato estructurado. Una vez que se ha diseñado la herramienta de recopilación de datos, se recomienda que la pruebe en el campo antes de la recopilación de datos para asegurarse de que satisfaga sus necesidades durante las observaciones.

Sección 4.5.2. Cómo iniciar el contacto

Antes de entrar en el campo para realizar sus observaciones, es importante contactar primero a los responsables de los departamentos deinterés para explicar el proyecto y los fundamentos de la realización de las observaciones. Conseguir que los gerentes acepten apoyar el proyecto es fundamental para obtener acceso al personal de primera línea y asegurar que estos usuarios estén dispuestos a participar en las sesiones de observación.

Una vez que un responsable ha aceptado que su unidad participe, es aconsejable:

Planifique el momento de sus observaciones

Determinar si hay algún requisito de ropa o calzado en la unidad

Determinar si se requerirá un formulario de consentimiento firmado de cada

miembro del personal y/o paciente que se esté observando (ver Apéndice A para

descripción y muestra)

Presentar el proyecto y los observadores (recopiladores de datos) al personal,

idealmente como parte de una reunión del personal

El establecimiento de una persona de contacto, que puede o no ser el responsable, puede ser extremadamente útil en el cumplimiento de estas tareas. Se requerirá una persona de contacto para cada área clínica donde usted estará observando. Además de estas tareas preparatorias, su persona de contacto también puede ser invitada a ayudarle a recopilar artefactos tales como formas, o desechables, y para verificar la exactitud de los datos de observación después de que se han consolidado.

Sección 4.5.3. Asignación de tiempo

Al planificar el momento de sus observaciones, es necesario analizar analizarlo con el responsable para encontrar un tiempo que en el que no sea una molestia para el personal que se encuentre trabajando en ese momento. También es posible que desee considerar la observación del personal durante el comienzo del turno, al final del turno, durante el cambio de turno y durante las horas pico. Observar durante estos tiempos más complicados puede proporcionar ideas únicas y muy valiosas en comparación con los tiempos/horas más típicos.. Planee reunirse con su persona de contacto en la unidad el día de su primera sesión de observación.

Sección 4.5.4. Hacer sentir cómodos a los participantes

El aspecto más importante de realizar observaciones es asegurarse de que el personal se sienta cómodo mientras están siendo observados. Esto significa que los observados deben

34

saber que no es su rendimiento el que se está evaluando, sino que están siendo observados para entender si sus necesidades están siendo satisfechas por las tecnologías, procesos y entornos con los que interactúan. Si ve que el personal tiene dificultades o trabaja en torno a aspectos de un sistema, estas son oportunidades para aprender sobre los desafíos que enfrentan y para pensar en soluciones que podrían apoyarlos en hacer su trabajo más seguro y más eficiente.

El personal debe sentirse cómodo sabiendo que no compartirá los detalles de sus prácticas de trabajo, u opiniones, con otros, en particular con sus superiores; si puede hacer que el personal se sienta cómodo mientras observa, estarán mucho más dispuestos a participar en el proceso de observación y compartir información con usted. Una manera de aclarar esto es proporcionar a los participantes un formulario de consentimiento para que firmen en el que se explica cómo se utilizará la información recopilada durante la sesión de observación. Dependiendo del tipo de trabajo que esté haciendo, esto puede ser requerido. El Apéndice A: Confidencialidad y anonimato describe cómo y cuándo obtener el consentimiento informado y proporciona una plantilla de formulario de consentimiento de muestra.

El personal puede ser una gran fuente de información y en general entienden los problemas mejor que nadie, ya que viven y respiran estas tecnologías todos los días. Aunque el personal a menudo tiene grandes ideas para las soluciones, a veces no tienden a presentarlas porque no tienen ninguna experiencia de que sus ideas resulten en cambios, y puede sentirse desmotivados. Cuando el personal es observado y tiene la oportunidad de aportar sus experiencias, desafíos e ideas a alguien que es responsable de incorporar su retroalimentación en un proceso de cambio (por ejemplo, un proceso de adquisición/compra), puede ser una experiencia muy estimulante para todos los involucrados. A menudo, los empleados que son más antiguos, extrovertidos u opositores tienen más oportunidades de contribuir. Cuando sea posible, se aconseja buscar a los participantes del personal que representan diferentes perspectivas (por ejemplo, senior y novatos, extrovertidos y opositores, así como tranquilos y reservados) para asegurar que se incluya una amplia gama de necesidades e ideas.

Sección 4.5.5. Qué traer

Los materiales útiles para realizar observaciones incluyen:

Ropa apropiada, idealmente con bolsillos, que le ayude a mezclarse (por ejemplo,

una bata de laboratorio, matorrales, o lo que se use generalmente en esa área)

Calzado apropiado (por ejemplo, zapato cerrado)

Un distintivo de identificación

Un portapapeles o superficie ligera y dura para escribir

Un cuaderno y / o herramienta de recopilación de datos

Formularios de consentimiento (si es necesario, ver Apéndice A: Confidencialidad

y Anonimato)

Dos bolígrafos (diferentes colores pueden ser útiles)

35

Una cámara

Refrescos (por ejemplo, café y muffins) para todo el personal de la unidad

(opcional)

Asegúrese de que no está planeando llevar lo siguiente;

Su propia comida / bebida

Artículos pesados, o cosas que son difíciles de llevar

Ropa o calzado incómodo

Artículos perfumados (artículos con perfumes o desodorantes pesados)

Personas que no forman parte del equipo del proyecto

Proveedores de la tecnología investigada

Sección 4.6. Recopilación de datos por observación

Sección 4.6.1. Inicio de la sesión de observación

Comience encontrando a su persona de contacto en la hora de observación programada. Si no está familiarizado con el área clínica, pídale a su persona de contacto que lo lleve a una visita rápida a la instalación para que le muestre dónde se encuentran las cosas y pídale que le presenten a algunos de los miembros del personal del turno. Cuando esté listo para empezar a observar, acérquese a uno de los miembros del personal y proporcione una breve introducción de usted y el proyecto.

Explique que espera observar cómo se llevan a cabo las tareas o los procesos y que no está allí para evaluar su rendimiento, sino que desea observarlos para entender si sus necesidades están siendo satisfechas por las tecnologías, los procesos y los entornos con los que interactúan (puede indicarlo más específicamente en el contexto de la tecnología o del sistema en el que se está centrando). Pregunte si se sentirían cómodos observándose y dígales que pueden detener la sesión de observación en cualquier momento. Si están abiertos a ser observados y se requiere un formulario de consentimiento (Apéndice A), pídales que lo firmen; si dicen que no les gustaría ser observados, acercarse a otro miembro del personal y preséntese y presente el proyecto de nuevo. Un ejemplo de secuencia introductoria se proporciona en la Figura 6 a continuación.

36

Figura 6. Ejemplo de guión introductorio para iniciar la sesión de observación

Ejemplo de guión introductorio

"Hola, mi nombre es Charlie y soy del departamento de Ingeniería Biomédica. Nuestro hospital está comprando nuevas bombas de infusión y soy parte del equipo que está evaluando los dispositivos disponibles para ver cuál sería el mejor para nuestro hospital. Como parte de mi evaluación voy a ver cómo las diferentes bombas satisfacen sus necesidades como enfermera, y lo fácil que será utilizarlas.

Lo que me gustaría hacer hoy es observarla y tomar notas mientras usa nuestra bomba de infusión actual. Cuando observo, no la estaré evaluando, sino más bien, estoy interesado en aprender más acerca de cómo nuestra bomba actual encaja en su flujo de trabajo. Estaré observando cosas como las diferentes maneras como usa la bomba actual, de dónde obtiene la información necesaria para programarla, qué documentación tiene que llenar para cada infusión y qué elementos utiliza en su entorno, como órdenes, formas, etiquetas, mangueras y suministros de limpieza, que apoyan el uso de la bomba. También estaría encantado de escuchar cualquier de sus ideas sobre la bomba actual para que podamos considerar estas cosas en el futuro con la nueva bomba. Cualquier idea que tenga sobre cómo las nuevas bombas deberían funcionar también sería extremadamente útil.

Probablemente se sienta un poco extraño que la observe al principio, pero si está de acuerdo, por favor, sepa que no estoy recopilando información sobre su actuación, o evaluándola de ninguna manera, y no compartiré mis observaciones de usted con sus colegas o sus superiores. Sólo estoy interesado en información relacionada con las bombas y cómo hacer que las nuevas bombas funcionen mejor para usted. En mis notas, y cuando comparto esta información con el equipo del proyecto, nunca se identificará por su nombre. Además, puede detener la sesión de observación en cualquier momento. Sólo dígame si quiere que deje de observarla. ¿Todo suena bien?"

"Sí, esto está bien."

"¡Muchas gracias! Además, ¿estaría bien si tomara algunas fotos mientras tanto? Me aseguraré de no tomar ninguna foto de los pacientes, identificación, o información de salud personal. Si alguna información personal es capturada por accidente, será eliminada "

37

Sección 4.6.2. Mientras observa

Al principio, es probable que la persona observada realice sus tareas más cuidadosamente o conscientemente de lo normal (ver discusión del Efecto Hawthorne en la Sección 4.8.1), pero con el tiempo, si usted es capaz de observar sin interferir y puede hacer que los miembros del personal se sientan cómodos con su presencia, comenzarán a actuar normalmente y usted verá una representación más exacta de cómo funcionan en la realidad. A medida que observa, trate de no interferir, y asegúrese de que sus observaciones no están afectando la capacidad del personal para proporcionar atención al paciente. También, asegúrese de considerar la comodidad de cualquier paciente y miembros de la familia involucrado. En general, es una buena idea preguntar a la enfermera que está observando que le presente a los pacientes (si son conscientes) y su familia para que quede claro por qué está allí tomando notas. Además, asegúrese de no hacer comentarios o plantear preguntas que puedan ser percibidas como alarmantes para los pacientes o su familia frente a ellos. Encuentre un momento lejos de la cama del paciente para hacer estas preguntas.

Si se está adoptando un enfoque estructurado mientras observa, utilice su herramienta de recopilación de datos para registrar cualquier observación. Puede que le resulte difícil llenar un formulario de recopilación de datos estructurados en el campo, incluso si ha invertido tiempo para desarrollarlo. Mientras observa, las tareas pueden no ocurrir en la secuencia que usted espera, y pueden surgir desafíos que nunca se anticipó. Esté preparado para adaptar su enfoque a la recolección de datos a medida que está observando, para aprovechar al máximo su tiempo (por ejemplo, tomar notas durante la observación y rellenar el formulario de recolección de datos inmediatamente después de su sesión de observación).

Si se está llevando a cabo un enfoque exploratorio, utilice su cuaderno para registrar notas sobre lo que está viendo como está sucediendo. Una trampa común mientras se observa es quedar atrapado en "ver el espectáculo", en lugar de grabar notas sobre lo que se está observando. Otra experiencia común al comienzo de la recolección exploratoria de datos es una sensación de no saber qué buscar, o no ver nada que parece relevante. Estas experiencias son normales. Tomará algún tiempo para familiarizarse con el medio ambiente y para diferenciar en lo que debe centrarse para las metas de su trabajo. Si no está acostumbrado a estar en el entorno clínico, puede tomar algún tiempo para acostumbrarse a estar cerca de los pacientes y comprender todos los equipos y sistemas antes de empezar a distinguir lo que es relevante para su proyecto. Si tiene dificultad para identificar y registrar lo que es relevante mientras observa, piense de nuevo en la razón original para realizar observaciones y comience allí; Tenga en cuenta, sin embargo, que desea absorber todo lo que pueda sobre lo que está sucediendo a su alrededor. Aunque es posible que no vea problemas importantes de inmediato, después de algún tiempo observando los problemas comenzará a surgir.

38

Si es posible, tener más de un recolector/observador de datos es extremadamente útil porque mucha información es aprendida y procesada hablando de lo que se ha observado. También, la planificación para tener un tiempo de inactividad entre las sesiones de observación es importante, para permitirse un tiempo de reflexión en lo que ha visto, identificar cosas adicionales que hay que buscar y, si es posible, debatir. Dado que diferentes actividades pueden ocurrir en diferentes días y en diferentes momentos del día, tomar una pausa puede facilitar la observación de diferentes conjuntos de tareas, o en tiempos más propensos a errores como el cambio de turnos. Registre sus observaciones, impresiones, pensamientos, preguntas, etc. inmediatamente después de una sesión de observación para asegurarse de capturar tantos detalles como sea posible antes de comenzar a olvidar lo que vio. Esto es especialmente importante cuando se realizan varias sesiones de observación.

Las sesiones de observación pueden variar en longitud dependiendo del acuerdo hecho con la unidad, pero cuando el observador está saturado de información o la persona que está siendo observada muestra signos de no querer ser observada más, el observador debe tomar un descanso o moverse a observar a otra persona. Una buena regla general para la duración de una sesión de observación es apuntar a unas tres horas, pero en realidad, las sesiones de observación pueden variar desde aproximadamente una hora hasta ocho o doce horas, si se observa un turno completo.

Si tiene preguntas mientras está observando, es importante preguntarlas, pero tenga cuidado de no interrumpir a la persona que está observando en momentos inapropiados, especialmente si están realizando una tarea que es de seguridad crítica o requiere concentración. Para asegurarse de hacer preguntas en un momento adecuado, se recomienda que escriba cualquier pregunta en su cuaderno a medida que vienen, y luego pedir a la persona que está observando para hacerle saber cuándo está bien para hacer preguntas.

Las fotografías pueden ser una fuente muy efectiva de datos, y son especialmente útiles después de haber completado sus observaciones. Tener acceso a datos fotográficos puede ayudarle a recordar los detalles de tecnologías y entornos complicados, y facilitar la comunicación de sus hallazgos al equipo del proyecto. Mientras observa, trate de fotografiar tanto como sea posible, pero asegúrese de que el personal (y el paciente, si corresponde) se sienten cómodos y den su permiso antes de tomar cualquier fotografía. La mayoría de las

Consejo: Es común no notar ningún problema durante las primeras sesiones de observación al inicio de un nuevo proyecto. Esto es cierto tanto para observadores principiantes como para expertos y se produce porque cada proyecto requiere una cierta cantidad de comprensión contextual para poder identificar problemas potenciales. A medida que su comprensión contextual crece, también lo hará su capacidad para identificar problemas. En un estudio de campo llevado a cabo por el autor principal en la seguridad de la infusión intravenosa múltiple, realizó tres días de observaciones en cuidados intensivos antes de que los problemas comenzaran a emerger. Al final del proyecto, se identificaron más de 100 problemas/factores contribuyentes.

39

organizaciones sanitarias tienen estrictas reglas de privacidad, así que asegúrese de conocer y trabajar dentro de estas reglas durante la recopilación de datos. Cuando tome fotografías, trate de evitar capturar cualquier información de identificación, o personal de salud de los pacientes y el personal. Si captura alguna información de identificación, tendrá que ser cubierta o hacerse borrosa durante el análisis de datos para mantener la confidencialidad del personal o del paciente. Si la persona que está observando se siente incómoda al tomar fotografías debido a preocupaciones de privacidad, ofrezca mostrarles cualquier fotografía después de haberlas tomado para que pueda aprobarlas. Alternativamente, usted podría pedirle a algún miembro del personal que lo ayude a preparar las cosas para que cualquier información de identificación esté cubierta (por ejemplo, use un trozo de papel para cubrir el nombre de un paciente en una etiqueta). Tener el permiso del administrador de la unidad para tomar fotografías es muy recomendable, y también puede ayudar a hacer que el personal se sienta más cómodo. Antes de solicitar el permiso del responsable, es una buena práctica revisar las políticas de la institución con respecto a las fotos y la grabación de voz (consulte el Apéndice A: Confidencialidad y anonimato).

Sección 4.6.3. Cuándo dejar de observar

Después de haber pasado tiempo observando y comenzando a entender las tareas y problemas relevantes en el contexto de su trabajo, otro desafío puede ser saber cuándo dejar de realizar sus observaciones. Aunque no hay una regla específica para detenerse, cuando ya no puede identificar nuevos usuarios, tareas o problemas y llega a la saturación en términos de retroalimentación del personal, estos son indicadores clave de que es tiempo de dejar de realizar observaciones. Por supuesto, el cronograma del proyecto también puede dictar cuando las observaciones deben detenerse. Aunque no es ideal limitar estrictamente el tiempo de observación, recuerde que realizar algunas observaciones es mejor que ninguna, y más es mejor que menos.

Su comprensión del entorno de uso continuará desarrollándose incluso después de que se hayan completado las sesiones de observación, a medida que se analizan los datos y se aplican métodos adicionales de factores humanos. Es normal descubrir nuevas cosas que no se comprenden bien después de haber completado sus observaciones. Si esto sucede, no se preocupe; con el permiso del administrador, siempre puede volver a la unidad para realizar observaciones específicas adicionales.

El envío de una nota de agradecimiento a su persona de contacto, al responsable de la unidad y al personal de la unidad es altamente recomendable para hacerles saber que aprecia y valora sus contribuciones al proyecto. Comprométase a compartir cualquier resultado con ellos si están interesados en aprender cómo sus aportes tuvieron un impacto en el proyecto.

Sección 4.7. Qué hacer con los datos de observación

Si la recolección de datos observacionales es exploratoria o estructurada, usted tendrá una gran cantidad de datos descriptivos para trabajar. Saber cómo analizar estos datos puede ser extremadamente desalentador, y saber por dónde empezar, especialmente

40

para el observador novato, tiende a ser la mayor barrera para un análisis exitoso. Por lo general, un buen primer paso es organizar los datos de observación en temas para que puedan ser manejados con mayor facilidad. Los temas elegidos dependerán de los datos, y por qué fueron recogidos en primer lugar. Por ejemplo, los temas podrían ser elegidos basados en diferentes:

• Niveles del sistema (por ejemplo, usuario, tecnología, proceso, unidad clínica, hospital)

• Partes del sistema (por ejemplo, usuario, tecnología, formularios y documentación)

• Grupos de usuarios (por ejemplo, enfermeras, médicos, farmacéuticos, empleados)

•Áreas del hospital (por ejemplo, unidad de cuidados intensivos, departamento de emergencias)

Si los temas utilizados para organizar los datos son muy amplios, puede ser útil dividir los datos de cada tema en subtemas para mejorar la granularidad. Un ejemplo de este paso preliminar para el análisis de datos se muestra en la Figura 7. Para los propósitos de este ejemplo, se utilizó un enfoque exploratorio para aprender acerca de los problemas relacionados con la administración de múltiples infusiones intravenosas. Se incluye un extracto de los datos observacionales recogidos para el ejemplo.

Ejemplo de análisis de datos

Extracto: Datos crudos

- 12 camas disponibles en la unidad de cuidados intensivos

- las bombas muestran la tasa de volumen en letras más grande y la tasa de dosis en letra pequeña en la parte inferior de la bomba

- el farmacéutico está dedicado a la unidad

- el técnico de farmacia repone la medicación

- el técnico de farmacia entrega medicamentos

- 4-5 pacientes trasladados a la unidad por día, de la cirugía

- 3 camas en cirugía cardiaca unidad de cuidados intensivos

- la enfermera tiene 2 pacientes

- las bombas a veces hacen lentas las tareas de la enfermera

- no siempre usan la biblioteca de drogas

- la bomba responde lentamente a las pulsaciones de teclas

- a veces la enfermera tiene que volver a presionar los botones cuando la bomba no responde

- una vez se programó algo dos veces porque la bomba tardó en responder

41

- durante los paros, la biblioteca de drogas tarda demasiado

- los pacientes en paro necesitan grandes volúmenes de líquido

- política contra enfermeras de agencia de enfermería

- el personal debe tener experiencia en cuidados críticos

- orden de medicamentos (artefacto)

- fotografía de las pantallas de interfaz de la bomba

- fotografía de la etiqueta del medicamento

Extracto: Datos crudos organizados en temas

Tema 1: Estructura de la Unidad

- 3 quirófanos cardiovasculares envían pacientes a la unidad

- 12 camas de UCI para cirugía cardiaca

- 4-5 pacientes de cirugía transferidos cada día

Tema 2: Personal

- Todo el personal tiene experiencia en cuidados críticos

Subtema 2a: Enfermería

- Política contra el uso de enfermeras de agencia

- La proporción de enfermeras a paciente es de 1: 2

Subtema 2b: Farmacia

- Farmacéutico dedicado a la unidad

- Técnico de farmacia reabastece y entrega medicamentos

Tema 3: Bomba de infusión

Subtema 3a: Diseño de la bomba

- Las bombas muestran el índice de volumen en letra grande

- Las bombas muestran tasa de dosis en letra pequeña en la parte inferior de la bomba

- Fotografía de las pantallas de interfaz de la bomba

42

Subtema 3b: Temas de la bomba

- Grandes volúmenes de líquido se entregan rápidamente cuando un paciente está en paro, y la biblioteca de drogas toma demasiado tiempo para usarse en estas situaciones

- La bomba responde lentamente a las pulsaciones de teclas y si se vuelve a presionar un botón porque el usuario no cree que se recibió la primera pulsación, puede producirse un error de programación; esto ha sucedido a las enfermeras en la unidad, pero fue detectado

Tema 4: Información sobre la medicación

- Fotografía de la etiqueta del medicamento

- Orden de medicación (artefacto)

Figura 7. Organización de datos brutos en temas y subtemas

Una vez que los datos observacionales se han organizado en temas, son mucho más fáciles de utilizar como insumos para una serie de otros métodos de factores humanos, que se presentarán en el resto de este manual.

Sección 4.8. Limitaciones de las Observaciones

Antes de recopilar datos de observación, es importante considerar los siguientes desafíos y limitaciones:

Sección 4.8.1. El efecto Hawthorne

Como se puede imaginar, es probable que las personas mejoren o modifiquen su comportamiento si saben que están siendo observadas. En la literatura científica, este cambio de comportamiento se conoce como el efecto Hawthorne [27]. Si bien puede parecer que este efecto dificultaría la recopilación de datos de observación confiables, asegurarse de que el sujeto se sienta cómodo y sepa que sus habilidades y capacidades no están siendo evaluadas, sino que esel dispositivo o sistema que está utilizando el que está siendo evaluado puede ayudar a minimizar este efecto. Las modificaciones de comportamiento vistas al principio de un período de observación pueden disminuir con el tiempo si el observador puede demostrar que no está evaluando el desempeño de los observados y están verdaderamente comprometidos con la comprensión de su ambiente, tareas y desafíos. Además, cualquier riesgo o inquietud identificado durante las observaciones (es decir, sujeto al Efecto Hawthorne) puede ser considerado un punto de vista conservador en cualquier desafío o problema experimentado por los sujetos.

43

Sección 4.8.2. La inversión de tiempo requerida

Dependiendo del objetivo de sus observaciones, puede tomar varias sesiones de observación con personal múltiple, en varios entornos, para recolectar sus datos. Estas sesiones de observación pueden ocurrir en rápida sucesión o tener lugar durante un largo período de tiempo dependiendo de la frecuencia con la que se realizan ciertas tareas en el campo. A menudo, cuando se observa, ver desafíos imprevistos conducirá al profesional de los factores humanos a ampliar el alcance de sus observaciones con el fin de comprender mejor los factores que afectan a lo observado. En última instancia, el tiempo invertido en la observación puede estar dictado por factores externos tales como los recursos disponibles, la carga de trabajo o los plazos del proyecto, pero cuando sea posible, las sesiones de observación deben continuar hasta que se pueda describir claramente el uso de la tecnología o el proceso y no hay preguntas pendientes de respuesta.

Sección 4.8.3. Sesgo de Observador

Como observador, traerá un punto de vista sesgado a sus observaciones. Todas las personas tienen limitaciones humanas inherentes que afectan nuestra capacidad de ver, interpretar y recordar lo que hemos visto. Como todas las personas, vemos e interpretamos nuestro mundo a través de una serie de sesgos cognitivos (ver Sección 3.3.1.3); Tendemos a ver lo que esperamos ver, y a recopilar información de una manera que se ajuste a nuestras propias experiencias y expectativas. Estos sesgos inherentes pueden minimizarse a través de una mayor conciencia de nuestras limitaciones humanas, y pueden ser abordados de manera más sistemática a través de un enfoque estructurado de recolección de datos (Sección 4.6.1).

Sección 4.9. Observaciones adicionales Recursos

Artículos

1. Diaz-Navarlaz T, Pronovost P, Beortegui E, Seguí-Gómez M. Beneficios de la Observción

Directa en la Administración de Medicamentos para Detectar Errores. J Paciente Saf. 3

(4): pp200-207

Guías

2. Oullet M, Rainville M, Bouchard LM, Belley C. Guía para la observación directa de la

seguridad comunitaria. 2009. Gobierno de Québec.

http://www.inspq.qc.ca/pdf/publications/1005_DirectObservation_Vol12_e ng_.pdf

Capítulos de libros

3. Clancey WJ. Observación de prácticas de trabajo en entornos naturalistas. En A. Ericsson,

N. Charness, P. Feltovich y R. Hoffman (Eds.), Cambridge Handbook on Expertise and

Expert Performance. Nueva York: Cambridge University Press, pág. 127-145.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.89.9513&rep=re p1 & type

= pdf

44

Capítulo 5. Entrevistas, grupos focales y encuestas

Sección 5.1. Preparando el escenario

La recopilación de datos a través de la observación rinde una rica información sobre cómo las personas hacen las cosas, pero esta visión sólo proporciona parte de la historia. También es importante entender por qué se ha establecido un sistema, o se están haciendo las cosas, de una manera particular. Comprender por qué, desde la perspectiva del sujeto ayuda a evitar que usted, el observador, introduzca prejuicios asignando sus propias suposiciones a algo que ha observado. También es importante ayudarle a aprender sobre los modelos mentales de la gente, las preferencias y el conocimiento, en el contexto del uso de la tecnología. A veces las observaciones resultan en una comprensión de por qué el sistema funciona como lo hace; a saber, si usted tiene el tiempo y la libertad de hablar, y hacer preguntas a las personas que está observando. Sin embargo, en realidad esto suele ser difícil porque los que se observan están ocupados, con poco tiempo para responder preguntas en profundidad. Esta es la razón por la cual es una buena idea planear la recopilación de datos de varias maneras, desde múltiples sujetos, incluyendo el uso de métodos como entrevistas, grupos focales y encuestas.

Entrevistas, grupos focales y encuestas son métodos cualitativos de recopilación de datos utilizados para recopilar información de los sujetos haciendo preguntas. Son útiles para recopilar datos sobre las percepciones de los participantes, las preferencias de los usuarios o el conocimiento sobre un proceso, una tarea o un tema organizacional, y se aplican a menudo junto con observaciones (Capítulo 4). Sin embargo, no siempre se correlacionan con el rendimiento optimizado del usuario y la mejora de la seguridad del paciente. Esta disonancia es un fenómeno de factores humanos establecido llamado paradoja de rendimiento versus preferencia, [28] que establece que los usuarios no siempre tienen mejores resultados con los ítems que prefieren. Como resultado, asegúrese de interpretar los datos de las preferencias de los usuarios con precaución y junto con los datos de rendimiento de los usuarios. Para obtener más información sobre la generación de datos de rendimiento del usuario, consulte Capítulo 8, Pruebas de usabilidad.

Se pueden usar entrevistas, grupos focales y encuestas para recolectar datos que pueden ser de naturaleza exploratoria o estructurada y pueden realizarse en persona, por teléfono o electrónicamente. Las herramientas de recopilación de datos para estos métodos varían dependiendo del tipo de datos que se están recolectando y pueden variar desde un bloc de notas y una pluma hasta una serie formal de preguntas en encuestas electrónicas con respuestas predefinidas.

Los objetivos del proyecto, grupo sujeto y los recursos disponibles deben ser tenidos en cuenta para asegurar que los datos pertinentes se obtengan,en cuanto de planifica su recolección a través de entrevistas, grupos focales o encuestas. La identificación de participantes interesados puede ser un desafío, y antes de realizar entrevistas y grupos focales, es importante contactar primero a los responsables de los departamentos que le gustaría incluir como parte de su recolección de datos. Presentarse durante una reunión de personal puede ser una excelente forma de notificar al personal de las próximas entrevistas

45

o las oportunidades de los grupos de enfoque, para aumentar su interés y participación. Para las encuestas, considere trabajar con un responsable, persona de contacto u organización familiarizada con sus participantes objetivo, para mejorar su credibilidad, ayudarle a alcanzar tantas personas interesadas como sea posible y mejorar las posibilidades de que completen la encuesta.

Sección 5.2. Entrevistas

Las entrevistas son reuniones, generalmente realizadas en persona o por teléfono, donde un recolector de datos obtiene información de uno o más participantes. Las entrevistas pueden ser desde exploratorias, a semi-estructuradas, o estructuradas, con preguntas preparadas de antemano por el entrevistador que pueden ser más específicas o abiertas. Dependiendo de la naturaleza y el propósito de la entrevista, el mismo participante puede ser entrevistado una vez o varias veces, y la duración de la entrevista puede durar de sólo unos minutos a varias horas.

Sección 5.2.1. ¿Por qué usarlas?

Las entrevistas son una excelente manera de entender las percepciones, preferencias y conocimientos de una persona, en relación con sus roles y responsabilidades. Además de obtener información sobre por qué los sistemas funcionan de una manera particular, las entrevistas también pueden proporcionar una visión de los desafíos, oportunidades y soluciones desde la perspectiva de un participante individual. Las entrevistas permiten cierta flexibilidad al recolector de datos, ya que los temas de interés pueden ser investigados y explorados en tiempo real en base a las respuestas del entrevistado.

Realizar entrevistas con el personal antes de observar en el campo puede ayudarle a aclimatarse a lo que está a punto de ver de antemano, lo que puede agilizar sus sesiones de observación. Las entrevistas son también una gran manera de construir la relación con un miembro del personal que usted observará más adelante. Por el contrario, la realización de entrevistas con el personal después de la observación en el campo puede apoyar el desarrollo de preguntas de la entrevista y proporciona una oportunidad para aclarar los elementos que no se entienden completamente durante las sesiones de observación.

Desde la perspectiva de los profesionales de la tecnología biomédica, la realización de entrevistas puede ser útil para obtener:

Una visión general de cómo funciona un área clínica (por ejemplo, financiación,

personal, distribución, flujo de pacientes)

Información sobre políticas y prácticas de trabajo prescritas (es decir, cómo se

instruye a las personas para llevar a cabo su trabajo)

Información sobre la perspectiva, preferencias y experiencias de un sujeto

Información histórica sobre una tecnología en particular, problema o incidente

Confirmación y aclaración sobre los datos observacionales que se han recolectado

46

Sección 5.2.2. ¿Cuándo deben usarse?

Las entrevistas deben ser realizadas antes de observar en el campo si se requiere una comprensión del medio ambiente, o si el profesional de la tecnología biomédica quiere establecer una relación con un participante antes de observarlo. Además, si se requiere confirmación o aclaración sobre la base de lo que se observó en el campo, la realización de una entrevista es altamente recomendable.

Sección 5.2.3. Preparación para la recopilación de datos con entrevistas

Independientemente de si las entrevistas son de composición abierta, semiestructuradas o estructuradas, debe prepararse una lista preliminar de preguntas que sirva de guía de entrevista, para asegurar que se obtenga al mínimo una información requerida de un participante. Esto es especialmente importante si el participante sólo tiene una cantidad limitada de tiempo disponible para la entrevista. No importa si las entrevistas deben ser de tipo abierto, semi-estructuradas o estructuradas, las preguntas individuales deben ser abiertas para evitar sesgos o dirigir al participante y para solicitar tanta información y contexto como sea posible. Trate de familiarizarse con el conjunto de preguntas y de organizarlas en la guía de entrevistas para que pueda saltar fácilmente de uno a otro a medida que la conversación evoluciona. Lleve un registro de cualquier pregunta que ya haya sido contestada, así como cualquier pregunta pendiente, para que pueda optimizar su tiempo durante la entrevista.

Piense también acerca de su estrategia para registrar información durante la entrevista. Si es posible, haga arreglos para que una segunda persona asista a la entrevista para que una persona pueda facilitar la sesión mientras que el otro registra notas detalladas. Si no es posible tener dos personas presentes, considere otras estrategias para capturar datos, como tomar notas cortas o usar un grabador de audio para grabar la sesión. Si se prefiere un grabador de audio, asegúrese de tener el permiso adecuado (por ejemplo, consulte la discusión sobre el consentimiento y la aprobación ética de la investigación en el Apéndice A: Confidencialidad y Anonimato) y que el participante conozca al registrador y dé su permiso antes de grabar cualquier parte de la sesión.

Organizar para realizar la entrevista en un momento y lugar conveniente para el participante. Proporcione al participante cualquier información de antecedentes como el propósito de la entrevista o los objetivos del proyecto, y conteste cualquier pregunta que pueda tener sobre el proceso de la entrevista. Si el participante pide una lista de preguntas por adelantado, trate de darles una idea general de lo que va a pedir, pero normalmente no es necesario compartir las preguntas exactas con el participante por adelantado.

Sección 5.2.4. Realización de la recopilación de datos con entrevistas

Preséntese usted y el proyecto al participante si no está familiarizado con el propósito y los objetivos de la recolección de datos. Asegúrese de que todavía están dispuestos a participar y, si es necesario, pídales que firmen un formulario de consentimiento (Apéndice A: Confidencialidad y anonimato). Utilizando la guía de entrevistas, pregunte al participante las preguntas que preparó de antemano. Mantenga un registro de las preguntas que se le han hecho, así como de las respuestas, de modo que si el participante ofrece una respuesta a una

47

pregunta que todavía no se le ha hecho, no le pida al participante que responda de nuevo la misma pregunta.

Anote las respuestas del participante en tiempo real, y con el mayor detalle posible. Si no se pueden tomar notas detalladas durante la entrevista, inmediatamente después de la entrevista, escriba las respuestas de los participantes y cualquier idea o impresión que recuerde.

Después de la entrevista, envíe una nota de agradecimiento al participante para hacerle saber que aprecia y valora su contribución al proyecto. Si ellos están interesados en aprender cómo su respuesta impactó el proyecto, comprométanse a compartir cualquier resultado con ellos.

Sección 5.2.5. Limitaciones de las entrevistas

Mientras que las entrevistas son útiles para aprender acerca de las perspectivas, experiencias y preferencias del personal, no deben considerarse confiables para aprender acerca de cómo el personal completa su trabajo en la realidad. Muchos factores afectan el comportamiento y las percepciones humanas, por lo que cuando se entrevista a los sujetos acerca de cómo o con qué frecuencia realizan una tarea o interactúan con un dispositivo, aunque pueden estar recontando lo mejor de su capacidad, a veces existirá un desajuste entre lo que se comparte durante una entrevista y lo que se observa en la realidad.

Otra limitación de las entrevistas es que el entrevistador puede introducir un sesgo de forma no intencional, dependiendo de cómo se plantean las preguntas al sujeto. Cuando las preguntas conducen (por ejemplo, "¿no piensas que x es mejor que y?") O que los sujetos rápidos proporcionen sólo respuestas "sí" o "no" (por ejemplo, "¿consume mucho tiempo para ti? los datos obtenidos de las entrevistas no serán muy útiles en absoluto. Para evitar la introducción de prejuicios basados en la redacción de las preguntas de la entrevista, como el entrevistador, tratar de mantener las preguntas abiertas (por ejemplo, preguntar "¿qué pasó?" En lugar de "¿sucedió x?") Y evite introducir suposiciones en sus interpretaciones. Para asegurarse de que entiende completamente lo que se ha dicho, resuma verbalmente lo que usted piensa que dijo y pregúnteles si han interpretado correctamente.

El sesgo también puede introducirse por el orden en que se formulan las preguntas. Siempre que sea posible, equilibre los temas de la entrevista para minimizar este efecto.

Sección 5.3. Grupos focales

Un grupo focal es esencialmente una entrevista grupal, normalmente realizada en persona, donde un recopilador de datos obtiene información de múltiples sujetos a la vez. Un facilitador o moderador (que también puede ser el recolector de datos) encabeza un grupo focal, y aunque el tamaño de un grupo focal puede variar de sólo unos pocos participantes a muchos, un grupo de aproximadamente seis a ocho es ideal [29]. Un conjunto general de preguntas para promover la discusión entre los participantes del grupo focal se prepara de antemano, pero las preguntas también se pueden agregar o modificar en tiempo real según sea necesario. Un grupo focal es diferente de una entrevista no sólo en términos

48

del número de personas participantes, sino también porque los datos generados durante la sesión son sinérgicos:

Los participantes comparten sus propias perspectivas y preferencias y escuchan los puntos de vista de los demás, que en última instancia pueden cambiar los suyos.

Sección 5.3.1. ¿Por qué usarlos?

Los grupos focales proporcionan una oportunidad para que el profesional de los factores humanos se exponga a múltiples perspectivas de los participantes en un tiempo relativamente corto. Perspectivas, preferencias, desafíos y oportunidades pueden ser exploradas con base en las experiencias de los participantes. Cuando se les presenta un problema o una solución, es probable que los participantes de los grupos de enfoque compartan múltiples perspectivas y, si la sesión está bien facilitada, hablar a través de esas perspectivas como un grupo. Como los participantes están de acuerdo o en desacuerdo sobre los temas, se puede lograr una comprensión más clara de las diferencias dentro y entre los grupos de usuarios y las variaciones en las prácticas, preferencias y conocimientos dentro y entre los grupos.

Los grupos focales son una excelente manera de involucrar al personal de toda la organización en un proyecto y de compartir información entre unidades, especialidades o departamentos que normalmente no trabajan juntos. La participación en un grupo focal tiende a mejorar el interés y la motivación del personal en apoyar las etapas posteriores de un proyecto, especialmente si se ha realizado un grupo focal a principios del proyecto. La oportunidad de que el personal construya las ideas con el otro de una manera colaborativa puede ser una experiencia muy positiva para todos los involucrados.

Desde la perspectiva de los profesionales de la tecnología biomédica, la realización de un grupo focal será útil para obtener:

Exposición a múltiples perspectivas y experiencias de los participantes en un

corto período de tiempo

Un equipo multidisciplinario para pensar y colaborar en un problema o solución

común

Consenso de un grupo de partes interesadas sobre una cuestión o solución en

particular

Adquisición de una estrategia o solución, especialmente si los participantes de los

grupos focales ayudaron a darle forma

Sección 5.3.2. ¿Cuándo deben usarse?

Se debe llevar a cabo un grupo focal cuando se desea una gama de perspectivas o experiencias, cuando se busca una gama de soluciones candidatas o cuando se requiere un consenso o un compromiso de grupo.

49

Sección 5.3.3. Preparación para la recolección de datos con el grupo focal

Para que un grupo focal sea fructífero, similar a la preparación para una entrevista, una lista preliminar de preguntas debe ser desarrollada de antemano para asegurar que la información requerida se obtiene del grupo. Las preguntas deben ser abiertas para fomentar la discusión entre los miembros del grupo.

Si es posible, haga arreglos para que una segunda persona asista al grupo focal para que una persona pueda facilitar la discusión mientras que los otros registran notas detalladas. Facilitar un grupo focal requiere bastante habilidad para asegurar que cada participante tenga la oportunidad de compartir su opinión si lo desea, y para ayudar a mantener la discusión activa para obtener la información requerida. Si no es posible tener dos personas presentes, como para una entrevista, considere otras estrategias para capturar datos como tomar notas cortas o usar un grabador de audio para grabar la sesión si se permite y si todos los miembros del grupo focal consienten.

Organice para mantener el grupo focal en un momento y lugar conveniente para que asistan los participantes. Considere la posibilidad de traer café, jugo y bocadillos para los participantes, especialmente si la sesión está programada para durar más de una hora. Esté preparado para que los participantes se unan y abandonen el grupo focal durante la sesión, especialmente si se ha programado durante las horas de trabajo.

Sección 5.3.4. Realización de la recolección de datos con el grupo focal

Al comienzo de un grupo focal, preséntese y presente los objetivos de la sesión. Las presentaciones de los asistentes o una actividad para romper el hielo pueden ser útiles para que los participantes se sientan más cómodos, especialmente si no todos se conocen entre sí. Usando las preguntas que ha desarrollado de antemano, haga una pregunta al grupo y escuche la discusión que sigue. Registre la discusión en tiempo real y con el mayor detalle posible.

Facilitar un grupo focal requiere habilidades específicas de comunicación para asegurar que las ideas y opiniones de cada participante sean respetuosamente escuchadas. Es importante mostrar a los participantes que están escuchando activamente e interesados en lo que tienen que decir. Si hay un tomador de notas designado, puede ser útil proyectar notas mecanografiadas o escribir las perspectivas de los participantes en una pizarra o papelógrafo para que todos puedan ver lo que se ha discutido y el grupo puede asegurar que los pensamientos de cada participante han sido capturados con precisión. El uso de preguntas de sondeo y la aclaración de lo que los participantes han compartido pueden ser útiles para estimular la discusión más amplia entre los miembros del grupo focal.

Dependiendo de la dinámica del grupo, puede que tenga que solicitar respuestas, especialmente al comienzo de la sesión, preguntando a las personas si les gustaría compartirlas. A medida que avanza el grupo focal, las personas se vuelven más y más cómodas en compartir sus perspectivas.

Cuando uno o dos participantes dominan un grupo focal, es el papel del facilitador asegurar que todas las ideas y opiniones de los participantes sean respetuosamente escuchadas y que todos tengan la oportunidad de contribuir si lo desean. Como facilitador,

50

trate de solicitar respuestas de todos los participantes haciendo preguntas específicas a personas específicas para darles una oportunidad de compartir.

Para obtener información adicional y orientación sobre la realización de grupos focales, consulte el recurso de herramientas para llevar a cabo los grupos focales incluido en la Sección 5.6.

Sección 5.3.5. Limitaciones de los grupos focales

Cuando uno o dos individuos dominan un grupo focal, este no proporcionará al profesional de la tecnología biomédica una visión equilibrada o consensuada de las experiencias, perspectivas y preferencias del grupo. Para evitar esto involucre, o tome el rol de un facilitador efectivo que anime a todos los miembros del grupo a compartir sus opiniones. Esto puede ser un reto, dependiendo de las diferentes personalidades, las relaciones jerárquicas y la cultura organizacional del grupo. Presione para que una sola persona hable a la vez y asegúrese de que los miembros del grupo sean respetuosos uno del otro. Trate de evitar tener un miembro del personal y su jefe en el mismo grupo focal porque el miembro del personal puede sentirse incómodo hablando libremente debido a la presencia de su jefe.

Sección 5.4. Encuestas

Las encuestas son herramientas de recolección de datos, administradas por un recolector de datos, para obtener información de los sujetos. Las encuestas incluyen un conjunto escrito de preguntas, preparadas de antemano, para reunir una gama de respuestas predefinidas y abiertas de los sujetos. Las encuestas pueden variar en contenido, formato, longitud y mecanismo de entrega, dependiendo del propósito de la recolección de datos y de los sujetos que se pretenden.

Sección 5.4.1. ¿Por qué usarlos?

Las encuestas pueden ser un medio eficiente y rentable de recolectar datos sobre las perspectivas, preferencias y conocimientos de muchos participantes en un tiempo relativamente corto, sin tener que coordinar los horarios o ubicaciones de los participantes. Las preguntas de la encuesta exploratoria o abierta ayudan al recopilador de datos a comprender la gama de experiencias y preferencias de los participantes, mientras que las preguntas más estructuradas arrojan luz sobre las percepciones y preferencias de la mayoría de los sujetos. Dependiendo del diseño de la encuesta, la información estandarizada entre múltiples encuestados puede ser comparada y cuantificada mediante el análisis estadístico.

Algunos miembros del personal pueden preferir completar una encuesta a participar en otros métodos de recopilación de datos, como entrevistas o grupos focales, porque las respuestas de la encuesta pueden permanecer anónimas y los participantes pueden tomar tiempo para reflexionar antes de responder a una pregunta.

Desde la perspectiva de los profesionales de la tecnología biomédica, la realización de una encuesta será útil para obtener:

51

Información demográfica sobre un grupo de participantes

Información sobre el nivel de experiencia de un grupo de participantes

Una comprensión de la gama de percepciones, preferencias o conocimientos de

los encuestados

Una comprensión de las percepciones, preferencias o conocimientos de la

mayoría de los encuestados

Conjuntos de datos estandarizados para realizar análisis estadísticos descriptivos

sobre las perspectivas y preferencias de los participantes

Sección 5.4.2. ¿Cuándo deben usarse?

Las encuestas deben ser administradas cuando se desean las perspectivas, preferencias o conocimientos de muchas personas, o cuando es difícil programar a los participantes para entrevistas debido a su disponibilidad o ubicación geográfica. Las preguntas exploratorias deben ser usadas cuando se desea una gama de perspectivas y se deben usar preguntas estructuradas cuando se requiere una comprensión más estandarizada del promedio o la mayoría de los encuestados.

Sección 5.4.3. Preparación para la recolección de datos con la encuesta

Las preguntas de la encuesta deben prepararse con antelación independientemente de si la encuesta se presentará en papel o en formato electrónico. Las preguntas deben ser adaptadas en función del grupo de participantes objetivo y si se desean respuestas abiertas (exploratorias) o cerradas (estructuradas). Un ejemplo de enfoque de análisis exploratorio versus estructurado de una pregunta de encuesta se incluye en la Figura 8.

Pregunta exploratoria

¿Qué función (es) de bomba inteligente (s) utiliza más frecuentemente?

____________________________________________________________________________________________

____________________________________________________________________________________________

Pregunta estructurada

De las características de la bomba inteligente que se enumeran a continuación, ¿cuál de ellas utiliza con mayor frecuencia? (Marque todas las que aplican)

Biblioteca de medicamentos

Calculadora de tarifas

Calculadora del área de la superficie corporal

Función Bolus

Figura 8. Comparación de una pregunta exploratoria versus una encuesta estructurada

52

Como puede ver, con la pregunta más estructurada, los participantes deben seleccionar sus respuestas de la lista suministrada, mientras que la versión exploratoria deja al participante pensar en las respuestas más correctas desde su perspectiva. La pregunta exploratoria es probable que extraiga una amplia gama de posibles respuestas de los participantes, mientras que en la pregunta estructurada es probable que los participantes se enfoquen en una o más de las opciones proporcionadas.

Si un objetivo de su encuesta es poder analizar datos usando estadísticas descriptivas, se requerirá un enfoque de encuesta más estructurado. En este caso, además de las preguntas sobre los objetivos del proyecto y el contenido de interés, también se recomienda incluir preguntas estructuradas sobre el género, el rango de edad, el nivel de experiencia y el tipo de unidad o especialidad de una persona para proporcionar un contexto demográfico adicional a las respuestas de la encuesta .

Al desarrollar su encuesta, otra consideración importante será cómo mantener un registro de los encuestados para asegurar que se puedan identificar las respuestas duplicadas. Esto tiende a ser más fácil cuando las identidades de los participantes no necesitan ser mantenidas confidenciales, ya que el nombre del entrevistado puede usarse como identificador. Sin embargo, cuando las identidades de los participantes deben permanecer en el anonimato, otros enfoques para el seguimiento de los encuestados tendrán que ser utilizados. Un posible enfoque es vincular un nombre de participante confidencial a un número de identificación de participante anónimo para que la identidad del entrevistado no se incluya directamente en la encuesta. Otra opción sería utilizar una herramienta de encuesta electrónica, que limita el número de respuestas que vienen de una sola computadora a una, e incluye características como enlaces de encuesta personalizados para ayudar a administrar el seguimiento de múltiples encuestados. Si le preocupa recibir respuestas duplicadas, puede incluir una declaración jurada o declaración al principio o al final de su encuesta, indicando que al marcar la casilla, el participante confirma que no ha completado su encuesta. El rigor con el que se rastrean las respuestas y las restricciones para incluir información personal o números de seguimiento dependerá de su institución, sus sujetos y los objetivos del proyecto.

Antes de distribuir su encuesta a los participantes, es altamente recomendable validarlo a través de pruebas piloto con uno o más usuarios finales representativos para asegurarse de que está claro y cubre el material que es relevante para sus participantes objetivo. Esto se debe a que cuando las encuestas no están claras, los datos recopilados pueden no reflejar con precisión las opiniones o experiencias de los participantes. Si tiene una persona de contacto con el proyecto, póngase en contacto con ella para ver si estaría dispuesta a revisar su encuesta o si conoce a un colega que podría revisar su encuesta en su lugar.

Sección 5.4.4. Realización de la recolección de datos

Una vez que su formulario de encuesta esté completo y haya sido validado, los participantes pueden ser invitados a completar su encuesta en persona o electrónicamente, dependiendo de su población objetivo y el número de personas que espera para completar su encuesta. Si puede invitar a los participantes a completar su encuesta a través de una

53

fuente conocida y confiable, como un colega clínico, un gerente clínico o una organización reconocida, a menudo es más fácil conseguir que su población objetivo participe. Alternativamente, si usted puede informar a los participantes sobre su encuesta en persona, como durante una reunión de personal, puede responder a cualquier pregunta sobre la encuesta o el proyecto, y los participantes potenciales más tarde esperarán su invitación para completar la encuesta.

Sección 5.4.5. Limitaciones de las encuestas

Cuando las encuestas se usan aisladamente de otros métodos de recopilación de datos, como observaciones o incluso entrevistas y grupos focales, existe el riesgo de que se recopile un cuadro incompleto de las perspectivas, percepciones y conocimientos de un tema. A diferencia de las entrevistas y los grupos focales, donde el recopilador de datos puede reformular preguntas o profundizar en un tema en tiempo real, las encuestas son herramientas estáticas de recolección de datos. Si las preguntas son confusas o se malinterpretan fácilmente, los datos recopilados a través de una encuesta no serán útiles para el profesional de la tecnología biomédica e incluso pueden ser incompletos o incorrectos. Se recomienda encarecidamente probar la validez de una encuesta (es decir, qué tan bien la encuesta mide lo que se ha establecido para medir) para asegurarse de aprovechar al máximo su herramienta de encuesta. Prueba piloto de su encuesta con un pequeño número de usuarios representativos para obtener retroalimentación sobre el diseño de la encuesta y para determinar la forma en que los encuestados interpretaron las preguntas que se plantearon es una buena manera de validar su encuesta.

Otra limitación de las encuestas es que cuando se utilizan para recopilar información sobre problemas e incidentes pasados, puede ser difícil diseñarlos para capturar el nivel de detalle necesario para comprender las causas raíz reales y los factores que contribuyen a esos problemas e incidentes. En consecuencia, el profesional de los factores humanos debe casi siempre interpretar este tipo de datos de encuesta en conjunción con los datos recogidos de otras fuentes.

Aunque los sujetos pueden estar más cómodos respondiendo a las preguntas de la encuesta que participar en una entrevista o grupo focal, aún puede ser difícil conseguir que los participantes completen una encuesta. Las encuestas tienen menos probabilidades de ser completadas por los participantes si son:

Demasiado largas

Tener poco valor percibido para el participante

Distribuido de una fuente desconocida (por ejemplo, una persona u organización

desconocida para el participante)

Acompañado por un período de tiempo demasiado corto o demasiado largo para

responder (2 semanas suele ser apropiado, ya que permite tiempo para las

personas que están de vacaciones o no en turno durante unos días).

Está saturado con demasiadas encuestas

54

No se presenta de manera oportuna (por ejemplo, las encuestas sobre equipos

particulares se distribuyen mejor inmediatamente después de su uso)

Una vez más, la prueba piloto de su encuesta con un pequeño número de usuarios finales representativos con el fin de solicitar retroalimentación es una buena manera de obtener información sobre si alguna de estas reglas empíricas han sido violadas.

Sección 5.5. Qué hacer con la entrevista, el grupo focal y los datos de la encuesta

Los métodos elegidos para analizar la entrevista, el grupo focal y los datos de la encuesta dependerán en parte del tipo de datos recopilados (por ejemplo, entrevistas estructuradas versus semiestructuradas) y de los objetivos del proyecto. Técnicas de análisis de datos cualitativos, tales como el método comparativo constante [30] se utilizan comúnmente para examinar estos datos. Sin embargo, como un grupo de gestión de la tecnología de la salud, la entrevista, el grupo focal y los datos de la encuesta por lo general se vinculan con los datos de observación, y se utiliza como una entrada a otras técnicas de análisis de factores humanos y métodos como análisis de tareas, HFFMEA y HFRCA. Las siguientes secciones de la Parte II de este libro discutirán estos métodos de factores humanos con mayor detalle.

Sección 5.6. Recursos adicionales para entrevistas y grupos focales

Conjunto de herramientas para llevar a cabo grupos focales:

Http://www.rowan.edu/colleges/chss/facultystaff/focusgrouptoolkit.pdf

55

Capítulo 6. Análisis de tareas

Sección 6.1. Preparando el escenario

Una vez que los datos se han recopilado en el campo, usted necesitará una forma de dar sentido a los datos y compartirlo de una manera significativa con otros. Completar un análisis de tareas puede ser extremadamente útil para lograr estos dos objetivos. Tomar el tiempo para agrupar sus datos en un formato de análisis de tareas es una forma efectiva de identificar sistemáticamente cualquier suposición que se esté sosteniendo, o cualquier laguna en su propia comprensión.

Sección 6.2. ¿Qué es el Análisis de tareas?

Un análisis de tareas es una herramienta de documentación y análisis de datos que se utiliza para documentar las tareas específicas de un proceso, un flujo de trabajo, de acuerdo con sus pasos constitutivos. El análisis de tareas esencialmente descompone una actividad en pasos más pequeños para analizar la secuencia, condiciones y criterios de desempeño para completar una tarea.

Existen muchos marcos y enfoques para el análisis de tareas, con una revisión exhaustiva incluida en Kirwan y Ainsworth 1992 [31]. Los datos de observación, entrevistas, grupos focales y encuestas pueden servir como insumos para un análisis de tareas. La salida de un análisis de tareas suele ser un diagrama y / o una descripción de los pasos individuales necesarios para llevar a cabo un flujo de trabajo o proceso para completar un objetivo definido. A su vez, este diagrama a menudo se convierte en una entrada para otros métodos de factores humanos como análisis heurístico, pruebas de usabilidad, HFFMEA o HFRCA.

Sección 6.3. ¿Por qué utilizar el Análisis de tareas?

Un análisis de tareas es una excelente manera de consolidar datos de múltiples fuentes, como observaciones o entrevistas, grupos focales y encuestas, y puede servir como marco para vincular artefactos y fotografías recolectadas en el campo a partes específicas de los procesos relacionados con la tecnología que se está estudiando. La organización de sus datos de esta manera le ayudará a identificar cualquier laguna o incertidumbre en su conocimiento para asegurarse de tener una clara comprensión del trabajo que está llevando a cabo el personal.

Completar un análisis de tareas alentará a los profesionales de la tecnología biomédica a:

Pensar sistemáticamente las acciones y procesos de pensamiento requeridos de

un tema para que logren un objetivo definido.

Considerar los límites del flujo de trabajo definido o proceso, y las relaciones entre

las diferentes tareas.

56

Definir el alcance de un sistema, proceso o problema.

Pensar en el orden en que se completan las tareas, en la información requerida y

disponible en cada paso de la tarea y en cómo un sujeto pasa de una tarea a otra

para lograr su objetivo general.

Identificar las condiciones (conocimientos, herramientas, etc.) y los criterios de

desempeño para completar con éxito cada paso de la tarea y la meta final de la

tarea.

En el contexto de la seguridad de las tecnologías de la salud, el objetivo de un análisis de tareas es evaluar si las demandas que se hacen a los usuarios de una tecnología se encuentran dentro del rango normal de las capacidades humanas y si existen riesgos (factores humanos u otros) asociados a cualquiera de las tareas, que se pueden mitigar. Todas las tareas descritas anteriormente apoyarán al profesional de la ingeniería biomédica en el desarrollo de recomendaciones para el diseño / rediseño de las tareas y el desarrollo de procedimientos e instrucciones de uso más eficaces. También servirán como columna vertebral para otros métodos de evaluación de factores humanos.

Además de servir como entrada para otros métodos de factores humanos, la salida de un análisis de tareas es útil para comunicar su comprensión del sistema a otros. A menudo, cuando los procesos se muestran paso a paso, como en un análisis de tareas, incluso aquellos familiarizados con el proceso documentado se sorprenden de cuántos pasos discretos están involucrados. Un análisis de tareas puede ser un catalizador para simplificar un flujo de trabajo o proceso, porque cuando se ve de forma esquemática, puede ver ramas o secciones completas del diagrama que no se requieren para alcanzar la meta del sistema. Por lo tanto, el análisis de tareas puede ayudarle a identificar oportunidades para optimizar cómo se logran las metas de trabajo, con el objetivo final de proporcionar un cuidado más seguro y eficiente.

Desde la perspectiva de los profesionales de la tecnología biomédica, completar un análisis de tareas será útil para:

Consolidar y organizar datos de observaciones, entrevistas, grupos focales y

encuestas.

Resaltar cualquier laguna en su comprensión de un flujo de trabajo o proceso que

requiera mayor recolección de datos en el campo

Hacer que los complejos procesos de atención médica, los flujos de trabajo y las

interacciones de los usuarios con las tecnologías sean más comprensibles,

dividiéndolos en partes más pequeñas y más manejables.

Informar otros métodos de factores humanos como análisis heurístico, pruebas

de usabilidad, HFFMEA y HFRCA.

57

Sección 6.4. Cuándo utilizar el análisis de tareas

Después de haber recopilado datos observacionales y de entrevistas, grupos de enfoque y / o encuestas del campo, puede consolidarse, organizarse y documentarse mediante un análisis de tareas. La salida de un análisis de tareas puede ser una excelente herramienta de comunicación y si desea compartir sus datos con otros u obtener confirmación o aclaración sobre lo que aprendió en el campo, esta forma de documentación y análisis es altamente recomendable. Se debe completar un análisis de tareas antes de realizar un HFFMEA, HFRCA y, si se desea, antes de un análisis heurístico o prueba de usabilidad.

Sección 6.5. Preparación para un análisis de tareas

En preparación para un análisis de tareas, el profesional en tecnología biomédica debe dedicar tiempo a observar en el campo (Capítulo 4) para recolectar datos que servirán de base para el análisis de tareas. Si es aplicable, las entrevistas, grupos focales y / o encuestas deberían ser completados para servir como fuentes de datos adicionales (Capítulo 5).

Una vez que los datos se han recopilado es una buena idea revisar los objetivos del proyecto para pensar en el propósito y el alcance de su análisis de tareas. A continuación, debe elegirse un marco. Hay varios marcos de análisis de tareas disponibles, y el que usted elija dependerá del propósito de hacer un análisis de tareas. Cabe destacar el Diagrama de Acción-Decisión, o Diagrama de Actividades; Análisis de tareas jerárquicas (HTA); Análisis de tareas cognitivas; Técnica de Incidente Crítico; y el análisis del acoplamiento; una revisión comprensiva de los varios marcos del análisis de la tarea se incluyen en Kirwan y Ainsworth 1992 [31].

Para los fines de este libro, se presentará un marco de análisis de tareas único: el diagrama de flujo del proceso. Es probable que el diagrama de flujo del proceso sea el marco de análisis de tareas más útil para un profesional de la tecnología biomédica porque es un medio flexible de describir una amplia gama de flujos de trabajo y procesos. Típicamente, los diagramas de flujo de proceso están compuestos de formas y flechas estandarizadas que representan tareas y el flujo entre tareas, respectivamente. Proporcionan un medio para documentar acciones, decisiones, flujo de información y actividades. En términos de notación para un diagrama de flujo de proceso, se recomienda el Lenguaje de Modelado Unificado (UML) 2.0, ya que a diferencia de la mayoría de las otras anotaciones, este lenguaje gráfico permite al analista documentar actividades que ocurren en paralelo, lo que es común en la asistencia sanitaria. Un ejemplo de la salida de un diagrama de proceso se muestra en la Figura 9.

58

Figura 9. Ejemplo de un diagrama de flujo de proce so

Para la creación de un diagrama de flujo de proceso, necesita tener acceso a los datos recogidos en el campo, incluyendo notas, fotografías y otros artefactos, y un pedazo grande de papel y un lápiz, o un programa de computador (programas informáticos) con capacidad de hacer diagramas . En términos de programas informáticos hay varias opciones disponibles, que van desde código abierto a suites profesionales. Al seleccionar un programa de computador para su análisis de tareas, asegúrese de que se puede utilizar para crear diagramas de flujo. Un programa con una biblioteca UML es ideal porque permite arrastrar y soltar fácilmente las cajas y flechas necesarias para representar los elementos de un diagrama de flujo de proceso.

59

Sección 6.6. Completar un análisis de tareas

El primer paso al crear un diagrama de flujo de proceso es definir la meta y el alcance del flujo de trabajo o proceso que se está considerando. Enunciar el objetivo del flujo de trabajo asegurará que el diagrama cubre el proceso de interés, especialmente cuando un proceso abarca múltiples áreas clínicas, y definir el alcance del flujo de trabajo proporcionará los límites del diagrama. En el caso del ejemplo de la figura 9, el objetivo del procedimiento es administrar quimioterapia usando una bomba de infusión ambulatoria y el alcance del procedimiento abarca desde la recolección de suministros para la mezcla de quimioterapia hasta la infusión de medicamento al paciente. Las tareas que se producen antes y después de este alcance (por ejemplo, preparación de la orden de quimioterapia y fin de funcionamiento de la bomba después de infundir la medicación) no se incluyen en el análisis de tareas y, por lo tanto, no se muestran en el diagrama de flujo del proceso.

Determinar lo que constituye una tarea requiere un poco de práctica. Una forma de considerar las tareas es pensar en ellas como un agrupamiento sujeto / verbo / sustantivo. Esencialmente, ¿quién hace qué acción con / en qué objeto. Por ejemplo, una enfermera (sujeto) extrae el diluyente (verbo) del frasco (sustantivo). Algunas personas pueden encontrar útil crear una lista de tareas en un formato tabular antes de pasar a un diagrama de flujo de proceso. La Figura 10 proporciona un ejemplo de lo que podría parecer una tabla de tareas.

Figura 10. Lista tabular de tareas y subtareas que ayudan a organizar la información antes de crear un diagrama de flujo de proceso .

Cada uno de los símbolos gráficos de un diagrama de flujo de proceso se describe en esta sección y se muestra en la Figura 11. El punto de partida del diagrama de flujo del proceso es el "nodo inicial": un cuadro que representa la primera tarea en el proceso. A partir de aquí, los pasos de las tareas siguientes se documentan en cuadros unidos con flechas que indican la secuencia de las acciones/decisiones/ flujo de información asociado con la meta

60

del proceso y dentro del alcance del proceso definido. Una "bifurcación" y su correspondiente "unión" se usan en combinación para indicar las actividades que pueden ocurrir al mismo tiempo o en cualquier orden, con la estipulación de que todas esas actividades deben ser completadas antes de continuar luego de la unión. Un "punto de decisión" se indica con un diamante/rombo, donde sólo se seguirá una de las rutas disponibles. Determinar el camino a seguir en un punto de decisión, se incluyen "criterios de decisión" para mostrar las condiciones bajo las cuales debe tomarse ese camino. Cuando es relevante un tiempo transcurrido o el tiempo para iniciar una acción, se utiliza un símbolo de "período de tiempo/forma de reloj de arena". Un "carril" se utiliza para separar las tareas que ocurren en áreas clínicas diferentes, o que son hechas por diversas personas. Por último, se utiliza un "nodo final" para indicar el final del alcance del proceso que se diagrama.

Figura 11. Diagrama de flujo del proceso con tipos de símbolos definidos

Mientras trabaja a través de la adición de nodos al diagrama de flujo del proceso, consulte los datos recopilados a través de sus observaciones o entrevistas, grupos focales y

61

encuestas. Si hay incertidumbre en torno a un paso de la tarea, es importante tomar nota de esto y luego llevar a cabo actividades de recolección de datos dirigidas a resolver la incertidumbre y reflejar los resultados en el diagrama de flujo del proceso. La creación de un diagrama de flujo de proceso es un proceso iterativo, y es normal hacer un primer borrador del diagrama, tener brechas, huecos sin tenerlos definidos con exactitud y posteriormente realizar preguntas sobre el proceso y luego recopilar información adicional para concluir con un diagrama preciso. Uno de los principales desafíos a la hora de crear un diagrama de flujo de proceso es saber cuánto detalle incluir (consulte la Sección 6.8 Limitaciones del análisis de tareas). Para ayudar a crear un diagrama en un nivel apropiado de detalle tenga en cuenta el propósito y los recursos disponibles para el análisis de tareas. Hacer la pregunta "¿esta tarea o subtarea cae dentro del objetivo definido y el alcance de este flujo de trabajo" es otro medio de ayudarle a determinar si una tarea o subtarea debe incluirse.

Sección 6.7. Qué hacer con un análisis de tareas completado

Un análisis de tareas completado se requiere como entrada a otros métodos de factores humanos tales como HFFMEA, HFRCA. También se puede utilizar para ayudar a informar un análisis heurístico o una prueba de usabilidad. Incluso si no se realizan más análisis de factores humanos, un análisis de tareas por sí mismo puede ser una herramienta de análisis y comunicación inestimable, especialmente para entender un proceso e ilustrar la complejidad de un proceso para otros. También puede informar sobre el desarrollo de procedimientos para compensar el mal diseño y se utiliza para desarrollar nuevos procesos al cambiar el flujo de trabajo o trasladarse a un nuevo edificio o área de trabajo. Ser capaz de ver cómo las diferentes unidades clínicas interactúan entre sí añade una nueva y útil perspectiva.

Sección 6.8. Limitaciones del análisis de tareas

Aunque el análisis de tareas puede ser un ejercicio extremadamente útil, hay algunas limitaciones y escollos comunes a tener en cuenta.

Sección 6.8.1. La inversión de tiempo requerida

Un análisis de tareas es un proceso iterativo que requiere varias rondas de edición y actualización a medida que las partes interesadas revisan y proporcionan retroalimentación, basadas en sus perspectivas. Es importante incluir a los interesados que están involucrados en el proceso siendo documentados como revisores de su análisis y pedirles que proporcionen comentarios para asegurar que su documentación sea lo más precisa posible. Con la práctica, usted será más eficiente en documentar y describir flujos de trabajo o procesos basados en los datos que ha recopilado en el campo.

Sección 6.8.2. Saber qué datos incluir

Un fallo común cuando se realiza un análisis de tareas es saber qué datos incluir en el diagrama o en la descripción del proceso, tanto en términos de qué contenido incluir, como cuán detallado debe ser. Esta determinación dependerá en parte del contenido de los datos

62

con los que tenga que trabajar, así como de los objetivos del análisis de tareas y del propio proyecto. Por lo general, las acciones que se pueden considerar "constantes" en que se requerirían de cualquier persona en ese papel para lograr el objetivo definido, deberían ser incluidas en el análisis de tareas. Las acciones que se pueden considerar "específicas del contexto", en el sentido de que el sujeto bajo observación hizo algo que no estaba relacionado con el objetivo definido, generalmente no debería ser incluido en el análisis de tareas. La figura 12 incluye un ejemplo para mayor clarificación.

Una enfermera se está preparando para administrar quimioterapia a un paciente usando una bomba de infusión ambulatoria, y usted la observa hacer lo siguiente:

• Recoge la quimioterapia de la farmacia

• Habla con una enfermera sobre otro paciente

• Lleva la quimioterapia al paciente

• Verifica los cinco derechos de administración de medicamentos

• Responde a una pregunta del paciente sobre los efectos secundarios

• Comprueba la permeabilidad del sitio de acceso del paciente

• Programa la bomba de infusión introduciendo el volumen a infundir y la tasa de dosis

• Conecta al paciente

• Inicia la infusión

• Afloja la prensa de las mangueras

Usted debería incluir las siguientes tareas en su análisis de tareas:

• Recoge la quimioterapia de la farmacia

• Llevarla quimioterapia al paciente

• Verifica los cinco parámetros de administración de medicamentos

• Comprueba la permeabilidad del sitio de acceso del paciente

• Programa la bomba de infusión introduciendo el volumen a infundir y la tasa de dosis

• Conecta al paciente

• Inicia la infusión

• Afloja la prensa de las mangueras

Y querría excluir las siguientes tareas del análisis de tareas:

63

• Habla con una enfermera sobre otro paciente

• Responde a una pregunta del paciente sobre los efectos secundarios

Las tareas específicas del contexto (hablar con una enfermera acerca de otro paciente y responder a una pregunta del paciente acerca de los efectos secundarios) no deben ser incluidas en el análisis de su tarea porque no conducen directamente al objetivo del proceso de administrar quimioterapia a un paciente usando una bomba de infusión ambulatoria y, por lo tanto, no tendrían que ser llevadas a cabo por todas las personas en este papel.

Figura 12. Decidir qué datos incluir como parte de un análisis de tareas

En términos del nivel de detalle a incluir, esto dependerá en gran medida del propósito del análisis de tareas y de los recursos disponibles. Cuanto mayor sea el alcance y más detallado el análisis de tareas, más tiempo tomará documentar. No incluir suficiente detalle en un análisis de tareas, sin embargo, puede conducir a hacer suposiciones sobre el proceso y un fallo en identificar tareas potencialmente problemáticas, así como las posibles oportunidades de realizar mejoras.

Sección 6.8.3. No documentar el proceso real

Otro fallo común con el análisis de tareas es no documentar el proceso real seguido por los usuarios de la tecnología, y documentar el proceso ideal en su lugar. En la asistencia sanitaria es común que las prácticas de trabajo que cambian con el tiempo como resultado de las presiones de tiempo y de costes externos, así como los cambios en otros componentes del medio ambiente, y esto significa que las personas se vuelven creativos y buscar atajos, soluciones alternativas y nuevas formas de llevar a cabo sus objetivos. Cuando se completa un análisis de tareas para el flujo de trabajo o proceso ideal, a menudo no logra captar las tareas reales que se están haciendo, y no va a ser una descripción exacta o útil de lo que realmente está sucediendo en el campo. Un análisis de tareas del proceso ideal también limita su utilidad como una entrada para otros métodos de factores humanos.

Además, a menudo hay variabilidad en cómo se realizan las tareas y esto también necesita ser capturado en el análisis de tareas.

Por esta razón es extremadamente importante recolectar datos usando observaciones en el campo en lugar de asumir que el personal está operando de acuerdo a una política o protocolo. Aunque no intencional, es común que las personas describen lo que hacen de manera diferente a cómo se hace en la realidad, debido a las limitaciones de la memoria y la atención y los sesgos cognitivos (capítulo 3), y así las entrevistas, grupos focales y encuestas de datos, si bien es importante. Siempre debe ser apoyado por datos de observación antes de realizar un análisis de tareas.

64

Sección 6.9. Recursos adicionales de análisis de tareas

Artículos:

Human factors in anaesthetic practice: insights from a task analysis.

British Journal of Anaesthesia 100 (3): 333–43 (2008)

http://bja.oxfordjournals.org/content/100/3/333.full.pdf

Vasilakis, C., Lecnzarowicz, D., Lee, C., Application of unified modelling language (UML) to

the modelling of health care systems: An introduction and literature survey. International

Journal of Healthcare Information Systems and Informatics, 3(4), 39-52 (2008)

White Papers:

Embrey D, Task Analysis Techniques. 2000. Human Reliability Associates Ltd.

Available at:

http://www.cwsvt.com/Conference/Functional%20Assessment/Task%20Anal

ysis%20Techniques.pdfCapítulos de libros:

Capítulos de libros:

Fowler M, UML distilled third edition: A brief guide to the standard object modeling language: Chapter 1, Introduction. Third Edition ed., pp 1-16. Addison-Wesley, 2004

Libros:

Kirwan B, Ainsworth LK. A Guide to Task Analysis. London: Taylor & Francis, 1992

65

Métodos de evaluación de factores humanos

Un ingeniero de factores humanos recopila datos de usabilidad en la seguridad de infusión intravenosa múltiple durante una simulación en laboratorio con la enfermera de una unidad de cuidados intensivos.

66

Capítulo 7. Análisis heurístico

Sección 7.1. Preparando el escenario

Cuando una tecnología está mal diseñada, puede llevar a las personas a cometer errores mientras interactúa con ella. En salud, esto puede ser especialmente grave dada la complejidad de la tecnología y lo que necesitamos que haga. Muchas tecnologías en la asistencia sanitaria ofrecen funciones de supervivencia y apoyo a pacientes complejos con un estado clínico cambiante. Cuando esta tecnología está mal diseñada, puede ser responsable de errores que conducen a eventos de seguridad del paciente. Identificartecnologías o aspectos de su diseño que violen mejores prácticas de diseño de sistemas Humano-técnico [9] es una tarea con potencial de salvar vidas. El análisis heurístico es un método por el cual el diseño de la tecnología puede ser evaluado para determinar que tan desafiante es su operación por los usuarios.

Sección 7.2. ¿Qué es el análisis heurístico?

Un análisis heurístico es un método de análisis mediante el cual los expertos en usabilidad evalúan un diseño basado en las "reglas básicas" establecidas. Históricamente, se realizaron análisis heurísticos en sistemas de interacción hombre-computadora para evaluar las interfaces de software y determinar si tales sistemas podían considerarse "usables". Una guía bien establecida para diseñar buenas interfaces de usuario ha sido desarrollada por dos expertos líderes, Nielsen, con sus 10 Heurísticas de Usabilidad para el diseño de interfaces de usuario [32] y Schneiderman con sus Ocho Reglas de Oro para el diseño de interfases[33]. Más recientemente, Zhang [34] combinó y adaptó estos principios de diseño en 14 heurísticas de usabilidad para facilitar el análisis heurístico de los dispositivos médicos (Tabla 1).

Durante el análisis, se identifican características de diseño que violan una o más heurísticas. Para cada violación, el evaluador(es) identifica qué problemas de uso probablemente surgirán como resultado de la violación y el impacto potencial de cada problema de uso.

67

Tabla 1. Adaptación de 14 heurística de usabilidad de Zhang et al para dispositivos médicos

68

Sección 7.3. ¿Por qué utilizar el análisis heurístico?

Un análisis heurístico se puede utilizar para identificar rápidamente problemas de usabilidad con una tecnología que podría tener implicaciones potenciales de seguridad para los pacientes y el personal. A menudo se prefiere el análisis heurístico porque requiere relativamente pocos recursos para identificar problemas de diseño en comparación con muchos otros métodos de factores humanos, como pruebas de usabilidad.

Desde la perspectiva del profesional de la tecnología biomédica, completar un análisis heurístico será útil para:

Evaluar si un diseño de tecnología viola las mejores prácticas establecidas, lo que

podría aumentar la probabilidad de un error de uso y tener un efecto negativo en

la seguridad del paciente

Comparar el diseño de dos tecnologías similares

Predecir los tipos de errores de uso probablemente con un diseño de dispositivo

particular

Sugerir mejoras en el diseño de dispositivos para los vendedores para que sus

productos sean más seguros para sus pacientes y otros hospitales

Sección 7.4. Cuándo utilizar el análisis heurístico

Se debe incluir un análisis heurístico como parte de cada proceso de adquisición de tecnología. Antes de seleccionar una tecnología para la implementación en su institución de salud, es crucial asegurarse de que el dispositivo no promoverá el error de uso como resultado de la forma en que se ha diseñado. Tener un sentido de los problemas de diseño asociados con una tecnología antes de optar por implantarla puede ayudarle a tomar una decisión más informada, especialmente en el caso en que se estén comparando productos similares. Si se consideran varios productos como parte de un proceso de adquisición, un análisis heurístico puede ayudar a reducir el número total de productos que avanzan como parte del proceso de adquisición, siempre que se especifiquen criterios específicos de usabilidad en la solicitud de propuestas (véase el Capítulo 11 para más información sobre los factores humanos en la adquisición). Si el no cumplimiento de los pricipio heurísticos vistos, se identifican antes de una decisión de adquisición, es posible que tenga alguna influencia para sugerir mejoras al proveedor y su institución de atención médica tiene la oportunidad de identificar otros tipos de estrategias mitigadoras que se pueden implementar desde dentro de la organización.

Después de una falta , o evento adverso, el análisis heurístico se puede utilizar para determinar si las características de diseño del dispositivo pueden haber contribuido al incidente. Si un análisis heurístico descubre problemas de diseño, debe tomarse una acción inmediata para evitar que un incidente similar ocurra a otra persona. Cuando se trata de problemas con el diseño de la tecnología es importante señalar que la formación de personas para superar el diseño deficiente no es eficaz. Para obtener más información sobre la eficacia de diferentes estrategias de mitigación, consulte la Sección 3.5.

69

Por último, si alguna vez diseña soluciones tecnológicas como parte de su papel como gerente de tecnología biomédica, hacer que alguien lleve a cabo un análisis heurístico en su diseño proporciona una excelente oportunidad para minimizar el error de uso como resultado de una violación heurística. El análisis heurístico realizado a principios de un proceso de diseño centrado en el usuario puede agilizar el desarrollo de su solución y garantizar que satisfaga las necesidades de los usuarios.

Sección 7.5. Preparándose para el análisis heurístico

Sección 7.5.1. Familiarícese con el dispositivo

Al prepararse para un análisis heurístico, primero debe familiarizarse con la tecnología interactuando con ella para conocer su propósito, configuración, pantallas, modos de operación y cualquier componente de interfaz.

Además de aprender sobre el dispositivo en sí, también será importante comprender las tareas que se llevarán a cabo con la tecnología. Si la tecnología a ser evaluada ya se utiliza en el campo, se recomienda que se completen las observaciones y las entrevistas para saber cómo se utilizan típicamente. Si el dispositivo no se usa actualmente en el campo, trate de observar y entrevistar al personal usando un dispositivo que tenga un propósito similar a la tecnología de interés, o trate de observar en un entorno diferente (por ejemplo, otra instalación) donde el dispositivo está siendo usado. Esta información será importante para delinear una lista de tareas que los evaluadores recorrerán a medida que completen su análisis heurístico. Además de la observación, revisar el manual del producto y las instrucciones de uso son útiles para comprender las capacidades previstas del producto. Hacer esto antes de las observaciones le permitirá buscar evidencia de las características y funciones del dispositivo que se utilizan cuando se están realizando observaciones.

Sección 7.5.2. Crear una lista de tareas

Utilizando las observaciones y los datos de entrevistas, cree una lista o descripción paso a paso de las tareas que se llevan a cabo con la tecnología. Las tareas deben incluir todas las tareas realizadas por todos los grupos de usuarios, especialmente cualquier tarea de seguridad crítica o de peor escenario. Se recomienda realizar observaciones (Capítulo 4) para apoyar el desarrollo de la lista de tareas. Si hay más de un grupo de usuarios de la tecnología, asegúrese de incluir todas las tareas realizadas por cada grupo de usuarios único como parte de su lista de tareas. Esta lista de tareas se utilizará para guiar a cada evaluador paso a paso a través de su análisis heurístico. Es importante considerar la gama completa de tareas en el análisis heurístico, ya que es mucho más fácil hacerlo con este método que otros métodos de evaluación de factores humanos, tales como pruebas de usabilidad.

Sección 7.5.3. Identifique a sus evaluadores

Una vez que esté familiarizado con la tecnología a evaluar y las tareas que se realizan comúnmente, usted querrá identificar a sus evaluadores. Idealmente, las personas que tienen conocimiento del trabajo que se está realizando y los factores humanos deben ser incluidas como evaluadores para un análisis heurístico. Sin embargo, si esto no es posible, se

70

puede incluir una combinación de evaluadores con cualquiera de estas áreas de experiencia. Trate de proporcionar a sus evaluadores algún tiempo para familiarizarse con la heurística de usabilidad y el sistema de clasificación de gravedad antes de realizar un análisis. Si es posible, haga que los evaluadores sin experiencia practiquen la aplicación de la heurística de usabilidad y el sistema de clasificación de gravedad a un dispositivo u objeto diferente antes de llevar a cabo la evaluación de la tecnología. Por lo general, entre tres y cinco personas deben completar de forma independiente una evaluación heurística para identificar tantos problemas de usabilidad como sea posible teniendo en cuenta los objetivos y recursos disponibles para su evaluación [35].

Sección 7.5.4. Desarrollar una escala de clasificación de gravedad

El objetivo de la evaluación es identificar los problemas de diseño que pueden dar lugar a problemas de seguridad y usabilidad. Para cada problema de seguridad y usabilidad identificado, se debe asignar una clasificación de gravedad para ayudar a identificar las cuestiones de alta prioridad y para ayudar a facilitar una comparación entre productos, si el análisis se está haciendo para apoyar una evaluación comparativa. La Tabla 2 muestra una escala de clasificación de gravedad que fue adaptada basándose en el trabajo de Zhang et al. Sin embargo, cada análisis heurístico debe incluir el desarrollo de una escala de calificación que clasifique de la manera más adecuada los tipos de riesgos encontrados para la tecnología que se está evaluando. La Tabla 3 muestra una escala de clasificación de gravedad que incorpora preocupaciones de seguridad y usabilidad y se divide en sólo tres categorías de gravedad: baja, media y alta.

Tabla 2. Escala de gravedad adaptada de la escala presentada en Zhang et al (2003).

Gravedad Descripción

0 No es un problema de usabilidad. No se requiere corrección.

1 Sólo problema estético.

No necesita ser arreglado a menos que el tiempo adicional esté disponible.

2 Problema menor de usabilidad.

El arreglo de este debe tener poca prioridad

3 Principales problemas de usabilidad.

El arreglo del mismo es importante y debe darse alta prioridad.

4 Catástrofe de usabilidad.

El arreglo es imperativo y debe hacerse antes de que el producto pueda ser utilizado con libertad.

71

Tabla 3. Una escala de clasificación de gravedad que incluye tanto las preocupaciones de usabilidad como de seguridad.

Gravedad Descripción

1 Gravedad baja: Un problema que puede ser frustrante para el usuario.

2 Gravedad media: Un problema grave que puede ser muy frustrante para el usuario y / o dificulta al usuario completar la tarea correctamente y eficientemente.

3 Gravedad alta: Un problema crítico que puede ser altamente perjudicial para la capacidad del usuario de interactuar con el sistema y / o tiene potencial para causar daño al paciente.

Sección 7.5.5. Preparar una hoja de referencia para el evaluador y una plantilla de recolección de datos

Preparar una hoja de referencia para cada evaluador que les proporcione el marco para el análisis. Esto debe incluir lo siguiente:

Una lista de las 14 heurísticas y definiciones de usabilidad.

La escala de gravedad.

La lista de tareas que deben realizar para guiar su interacción con la tecnología a

medida que buscan problemas.

Además de una hoja de referencia, los evaluadores deben recibir una plantilla para registrar sus hallazgos, especialmente en el caso de que se desee un enfoque de análisis heurístico aislado, para asegurar que cada evaluador proporcione los detalles adecuados como parte de su análisis. Estos materiales deben ser entregados a los evaluadores por adelantado para que tengan tiempo de familiarizarse con ellos antes de la evaluación. Considere la posibilidad de incluir espacio para que los asesores proporcionen cuatro elementos clave de información para cada problema de usabilidad:

1. Dónde se produjo el problema de usabilidad en la interfaz

Al evaluar un componente de software de la tecnología, esta sería la pantalla donde existe la violación. Al evaluar un componente de hardware de la tecnología, es la ubicación física donde existe una violación de los principios heurísticos.

2. Una descripción del problema de usabilidad.

Para una aplicación de software o no de software en una tecnología, una descripción de la violación en palabras para ayudar a diferenciar entre violaciones similares descubiertas a través del análisis heurístico.

3. Una descripción de las posibles consecuencias del problema (si se conocen)

Una descripción del impacto potencial del problema en el usuario. Por ejemplo, el problema "no está claro lo que la opción del menú 'dosis de carga' significa" puede tener el

72

impacto "los usuarios pueden no ser capaces de averiguar cómo administrar lo que se refieren como una" dosis en bolo "causando un retraso en la administración Medicamento para perjuicio del paciente "

4. El código de la violación para el problema de usabilidad (opcional)

Incluir espacio para que los asesores proporcionen la combinación de números y letras que representa el tipo de violación encontrada es opcional. En algunos casos, los evaluadores pueden encontrar problemas de usabilidad que no están abiertamente incluidos en la Tabla 1, por lo que si se proporciona espacio para que el evaluador escriba el código de la violación, asegúrese de entienden que deben incluir cualquier violación identificada que no esté específicamente enumerada en la tabla.

5. La gravedad del problema de usabilidad

La clasificación de gravedad asignada a cada violación basada en la escala de clasificación de severidad desarrollada para el análisis.

Una plantilla de ejemplo para recopilar estas cuatro piezas clave de información se muestra en la Tabla 4.

Tabla 4. Ejemplo de una plantilla de recopilación de datos para los evaluadores

Código de la

Violación

Ubicación del

Problema de

Usabilidad

Descripción del Problema de

Usabilidad

Descripción de Consecuencias

Potenciales

Clasificación de Gravedad

1b Pantalla inicial

El uso del color (rojo y verde puede ser difícil de ver si es ciego al color)

El usuario puede seleccionar el folder incorrecto

3

1d Fuentes múltiples / uso inconsistente de la fuente en la pantalla

El usuario interpreta que las fuentes tienen significado implícito, cuando no es así

2

2a No está seguro del estado del sistema (no está seguro si el sistema se inicia por sí mismo, o si está esperando una acción del usuario)

El usuario presiona los botones mientras espera y hace selecciones en la siguiente pantalla sin saber lo que ha seleccionado

2

… … … … …

73

No es necesario asignar una puntuación numérica. Dependiendo del propósito del análisis heurístico y que tan bien se comprenden las implicaciones del problema, puede usarse una calificación cualitativa como alta, media y baja severidad (establecer definiciones para cada uno que sean relevantes para la tecnología que se está evaluando). El beneficio de una escala de calificación cualitativa es que reduce la probabilidad de que los tomadores de decisiones que están considerando los resultados del análisis heurístico (es decir, en una decisión de selección de tecnología) pondrán un mayor énfasis en los resultados del análisis heurístico que los resultados de otros métodos de factores humanos (por ejemplo, pruebas de usabilidad) porque es más fácil comparar datos cuantitativos que datos cualitativos.

Sección 7.5.6. Decidir sobre el formato para el análisis heurístico

Un análisis heurístico puede organizarse de dos maneras: o bien el evaluador completa su evaluación aisladamente; o el evaluador completa su análisis durante una sesión facilitada mientras el facilitador observa al evaluador completando las tareas y toma nota de cualquier problema, preocupación y preferencia identificado por el evaluador y luego finaliza la evaluación coordinando las observaciones con la heurística. Cuando los evaluadores realizan un análisis heurístico de forma aislada, pueden ayudar a reducir las oportunidades de sesgo no intencional, incluyendo la interacción con el facilitador. Sin embargo, la compilación de información sobre violaciones y observaciones de cada evaluador puede ser más intensiva en recursos para la persona en la función de facilitador. Cuando los evaluadores completan un análisis heurístico durante una sesión facilitada, puede ser más fácil para el facilitador compilar información sobre violaciones y observaciones debido al contexto adicional proporcionado al ver a los evaluadores pasar por cada tarea. Sin embargo, es más probable que el sesgo sea involuntariamente introducido a través de la interacción entre el facilitador y los evaluadores. El enfoque que use probablemente dependerá de los objetivos del proyecto y los recursos disponibles. Información adicional sobre cómo seleccionar un enfoque se puede encontrar en Nielsen's Cómo realizar un análisis heurístico (Sección 7.9 Recursos adicionales).

Sección 7.6. Completar un análisis heurístico

Tanto para un análisis heurístico aislado individual como para una sesión facilitada, asegúrese de que el evaluador tiene toda la información que necesita, así como el acceso a la tecnología que se está evaluando. Cada evaluador debe usar la hoja de referencia con el esquema de 14 heurísticas de usabilidad y de gravedad, junto con la lista de tareas y la hoja de recolección de datos para evaluar de forma independiente el diseño de la tecnología. Cualquier violación u observación debe ser registrada en la hoja de recolección de datos por el evaluador o el facilitador, dependiendo de cómo se ha establecido el análisis heurístico.

El evaluador debe pasar por lo menos dos rotaciones de la lista de tareas; primero para familiarizarse con el dispositivo y para indicar las impresiones iniciales y / o violaciones, y una segunda vez para identificar cualquier violación que pudiera haberse pasado por alto durante la revisión inicial.

74

Al describir la consecuencia de una violación o problema, es importante hacerlo en relación con los objetivos o el propósito de la tecnología. Por ejemplo, si se está evaluando una bomba de infusión intravenosa, su propósito es apoyar la administración de la medicación correcta, dosis, velocidad, ruta, tiempo, etc. Por lo tanto, las consecuencias de los problemas identificados deben identificarse en términos de su impacto sobre estas funciones (por ejemplo, una dosis incorrecta (demasiado alta), una dosis incorrecta (demasiado baja), un retraso en la administración de la medicación, etc., a menos que sean problemas generales de facilidad de uso, en cuyo caso la consecuencia puede ser la frustración del usuario. Describir las consecuencias en términos de las metas o el propósito del sistema facilita la asignación de las puntuaciones de gravedad, ya que la clasificación de gravedad debe ser la misma para todos los problemas que tengan las mismas consecuencias.

Sección 7.7. Qué hacer con un análisis heurístico completo

El objetivo de un análisis heurístico es producir un único informe que describa todos los problemas identificados, sus posibles consecuencias y la gravedad de esas consecuencias para apoyar uno o más de los siguientes objetivos:

Identificar si es probable que una tecnología de salud sea segura y fácil de usar, siempre que haya un buen ajuste entre el dispositivo y el contexto de uso (el ajuste debe ser evaluado usando otros métodos como las pruebas de usabilidad)

Comparar la seguridad relativa y la facilidad de uso de dos o más productos

Es importante tener en cuenta que el enfoque principal de un análisis heurístico es identificar y describir los problemas, en lugar de identificar la violación heurística correcta que está causando el problema. Las heurísticas son un medio para identificar los problemas, no los problemas en sí.

Una vez que cada evaluador ha completado su análisis heurístico, todos los datos deben ser agrupados en una sola lista de problemas con una descripción de la consecuencia y una puntuación de severidad asignada a cada problema. Este proceso es más eficiente si una persona introduce los datos en una sola hoja de cálculo y luego todos los evaluadores se reúnen para discutir cada problema hasta que se establezca lo siguiente:

La descripción del problema de usabilidad es clara y única de todos los demás

Las consecuencias se expresan en términos que se relacionan con el objetivo o

función general de la tecnología

Se asigna una clasificación de gravedad única. Tenga en cuenta, si no se puede

llegar a un consenso, es posible que desee utilizar el promedio ponderado de cada

puntuación de evaluadores.

Una vez que se han determinado las puntuaciones de gravedad para cada problema de usabilidad, la hoja de cálculo de recolección de datos debe organizarse para resaltar las infracciones más graves. Generar una lista de recomendaciones o acciones propuestas para abordar cada violación grave puede ser útil dependiendo del contexto del análisis heurístico.

75

Si es posible, las violaciones que se consideren graves deben ser tratadas inmediatamente de acuerdo con las acciones recomendadas identificadas.

Si se ha hecho el análisis heurístico para identificar de forma proactiva o retrospectiva si una tecnología implantada tiene problemas de usabilidad, se deben abordar las preocupaciones que se han identificado con el diseño de la tecnología. Como se indica en la Sección 7.4, es importante señalar que la formación de personas para superar una violación en el diseño es mejor que no hacer nada, pero no es una solución muy eficaz. Del mismo modo la confianza en las calcomanías de advertencia que puedan llevar los dispositivos no mitigarán con total efectividad los problemas. Si los cambios orientados al dispositivo son posibles, serán más efectivos. También se recomiendan cambios en el sistema que ayuden a minimizar la probabilidad, la gravedad y / o mejorar la detectabilidad. Para más información sobre la eficacia de diferentes estrategias mitigantes, véase la Sección 3.5.

Si el análisis heurístico se ha realizado con fines de adquisición, los resultados de la evaluación heurística pueden utilizarse para determinar si alguno de los dispositivos en competencia debe eliminarse desde el principio en el proceso de selección como resultado de cualquier defecto de diseño no reparable y catastrófico que haya sido identificado antes de realizar las pruebas de usabilidad.

Sección 7.8. Limitaciones del Análisis Heurístico

Aunque los análisis heurísticos son extremadamente útiles para identificar problemas de usabilidad con una tecnología, también hay varias limitaciones a considerar.

Sección 7.8.1. Método de Evaluación Informal

Un análisis heurístico no es un método sistemático, y es limitado en que los únicos problemas de usabilidad que se detectarán son los encapsulados por las propias heurísticas. Si un problema de diseño de un dispositivo particular cae fuera de las heurísticas 14, es poco probable que se identifique a través de un análisis heurístico. Además, asignar una puntuación de gravedad a cada problema de usabilidad tiende a ser un ejercicio subjetivo. Por estas razones, generalmente se considera que un análisis heurístico es un método de evaluación informal.

Sección 7.8.2. Se requieren varios evaluadores

Tener un solo evaluador para realizar un análisis heurístico no revelará todos los problemas de usabilidad con un diseño de tecnología. Dado que las personas tienen sus propias perspectivas y experiencias únicas, diferentes personas descubrirán diferentes problemas de usabilidad a medida que interactúan con una tecnología. Aumentar el número de evaluadores, por lo tanto, aumentará la proporción de problemas de usabilidad identificados a través de un análisis heurístico. Según Nielsen, es probable que un solo evaluador descubra sólo el 35% de los problemas de diseño de la tecnología [35]. Cuando el número de evaluadores se incrementa a cinco, sin embargo, se puede esperar que alrededor del 75% de los problemas de usabilidad sean identificados.

76

La relación entre el número de evaluadores y la proporción de problemas de usabilidad identificados no es lineal, por lo que sólo se obtendrá un beneficio mínimo a medida que el número de evaluadores se incrementa de cinco a diez o 15. Por esta razón, y para ayudar a controlar los costos , como directriz se recomienda incluir entre tres y cinco evaluadores al completar un análisis heurístico. Otro enfoque posible sería dejar de evaluar la tecnología una vez que se ha alcanzado la saturación de problemas, por lo que los asesores independientes posteriores no son capaces de identificar más problemas de diseño únicos. Cuando los evaluadores descubren problemas muy diferentes y hay poca consistencia o superposición entre las violaciones heurísticas encontradas, este es un indicador clave de que deben incluirse evaluadores adicionales. Los resultados de un análisis heurístico deben ser tratados con cautela si hay poca consistencia en términos de problemas encontrados entre aquellos que evalúan la tecnología o el sistema.

Sección 7.8.3. Expertos evaluadores deben participar

Idealmente, los expertos en usabilidad, como los profesionales de los factores humanos, deben llevar a cabo análisis heurísticos porque están capacitados para ver problemas que violan los principios de diseño de mejores prácticas. Además, deben incluirse expertos en la materia (por ejemplo, clínicos) para su comprensión de los procesos que se llevarán a cabo con la tecnología que se está evaluando. Asociar a un experto en usabilidad y a un experto en la materia para cada evaluación puede ser un medio eficaz de identificar una gama más amplia de problemas de cada evaluación. Si en cambio se invita a expertos en no usabilidad, se recomienda que antes de realizar una evaluación heurística, se dedique algún tiempo a familiarizarse y practicar cómo aplicar las 14 heurísticas a diferentes dispositivos. Para evaluadores menos experimentados, es posible que también desee considerar la inclusión de más evaluadores en una evaluación de lo que haría con los evaluadores experimentados con el fin de mejorar la probabilidad de descubrir problemas de usabilidad.

Sección 7.8.4. La tecnología se evalúa en aislamiento

Otra limitación de un análisis heurístico es que la evaluación se realiza normalmente en una tecnología aislada, sin considerar los usuarios, procesos o entornos en los que se utilizará ese dispositivo. Como resultado, algunos problemas de usabilidad sólo pueden salir a la luz una vez que la tecnología se considera en el contexto del sistema de uso. Por ejemplo, cuando se evalúa una bomba de infusión en una oficina bien iluminada, un experto en usabilidad puede no detectar problemas con el contraste entre el texto y el fondo, pero cuando las enfermeras usan esa misma bomba por la noche en la UCI, el texto puede ser bastante difícil de leer. Para ayudar a superar estos desafíos, además de un análisis heurístico, pruebas de usabilidad también es muy recomendable.

77

Sección 7.9. Recursos adicionales

Artículos periodísticos

Using usability heuristics to evaluate patient safety of medical devices” by

Jiajie Zhang et al.: Journal of Biomedical Informatics, 2003. 36: p. 23-30.

“Human factors engineering: A tool for medical device evaluation in hospital procurement decision-making” by Gill Ginsburg: Journal of Biomedical Informatics, 2005. 38(3): p. 213-219.

Sitios web

El grupo Nielsen Norman para la evaluación heurística http://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

78

Capítulo 8. Pruebas de usabilidad

Sección 8.1. Preparando el escenario

Cuando se evalúa un cambio de tecnología o sistema de forma aislada, se desconoce el efecto de otros factores como el entorno de uso, las tecnologías y el equipo de interconexión y la dinámica de equipo de múltiples proveedores. Poner esa misma tecnología en un entorno simulado y en manos de usuarios finales reales, sin embargo, puede revelar qué problemas o consecuencias imprevistas esperar cuando se implementa la tecnología o el cambio de sistema.

Mientras que durante la demostración de un proveedor de una nueva tecnología, la tecnología se muestra como un dispositivo independiente y los observadores deben considerar de manera independiente tantos 'que tal si…' como puedan pensar en el momento, para identificar cómo la tecnología se ajustará a su entorno y los procesos de trabajo, las pruebas de usabilidad permiten a la gente pensar y trabajar a través de tareas y dificultades asociadas de una manera sistemática, sin la asistencia de especialistas de productos altamente capacitados y dentro de un ambiente seguro.

Sección 8.2. ¿Qué es la prueba de usabilidad?

Las pruebas de usabilidad son un método de factores humanos que permiten evaluar cómo funcionará una tecnología o proceso en su contexto de uso. Identifica problemas relacionados con la facilidad de uso, la facilidad de entrenamiento y la efectividad general que en el cuidado de la salud rutinariamente conducen a problemas de seguridad.

Durante las pruebas de usabilidad, los usuarios finales representativos interactúan con la tecnología o proceso de interés en un entorno simulado. Un usuario final representativo es alguien que tipifica a las personas que estarían interactuando con el sistema real en el mundo real. Dependiendo del sistema de salud que se esté probando, los usuarios finales representativos podrían ser enfermeras, médicos, farmacéuticos, técnicos, empleados o pacientes. Además de la tecnología o proceso que se está evaluando, el entorno puede incluir otras personas y tecnologías que interactúan con la tecnología o proceso que se está estudiando.

Sección 8.3. ¿Por qué usar pruebas de usabilidad?

No importa cuán estrechamente los profesionales de la tecnología biomédica, los expertos en factores humanos o los usuarios finales inspeccionen una tecnología o un proceso, nunca podrán identificar todos los posibles problemas y potenciales errores de uso que podrían ocurrir. A menudo, esto se debe a que un dispositivo evaluado en aislamiento sólo proporciona una visión de la gama de posibles problemas de usabilidad. No es sino hasta que el dispositivo está en manos del usuario final, que está ejecutando tareas en escenarios reales y en un entorno representativo, que una imagen mas acertada puede verse. Del mismo

79

modo, no importa cuántas ideas y opiniones se recopilen acerca de una nueva tecnología o cambio de sistema, ello nunca será adecuado para formar la base de una decisión significativa. Esto es porque, a pesar de nuestras mejores intenciones, somos bastante limitados en nuestra habilidad de conciliar nuestras preferencias y desempeño;, a menudo preferimos productos o cambios que conducen a un pobre desempeño (véase Paradoja de desempeño versus preferencia, Sección 5.1).

La mayoría, aunque no todas las pruebas de usabilidad de la tecnología de la salud se realizan en un entorno simulado. Esto es extremadamente beneficioso porque significa que los sistemas pueden ser evaluados en escenarios complejos sin afectar inmediatamente la atención, o causar daño al paciente.

Sección 8.4. Cuándo usar pruebas de usabilidad

Las pruebas de usabilidad deben realizarse siempre que se necesite información sobre cómo funcionará una tecnología o proceso en su entorno de uso. Algunos ejemplos de cuándo es útil aplicar pruebas de usabilidad en hospitales es durante el diseño de una tecnología, la evaluación de una nueva tecnología o proceso, la modificación o personalización de una tecnología o proceso, como parte de una evaluación proactiva del riesgo y durante una investigación de incidentes.

Este capítulo describirá un enfoque general para las pruebas de usabilidad para evaluar una sola tecnología o proceso. Al final de este capítulo se describen las modificaciones a este enfoque para comparar múltiples productos del mismo tipo de tecnología.

Sección 8.5. Preparación para una prueba de usabilidad

La primera tarea para preparar una prueba de usabilidad es obtener una comprensión detallada del entorno de uso, los usuarios y los flujos de trabajo que están directa e indirectamente relacionados con la tecnología o proceso que se está estudiando. Por ejemplo, si se están evaluando monitores de pacientes, se necesitará un conocimiento detallado de los entornos, las personas y los flujos de trabajo asociados con el uso de los monitores, además de comprender el sistema de registro electrónico de pacientes (EPR) y los procesos relacionados con transformar la información desde los monitores al sistema EPR y recuperar y hacer uso de esta información. Todos los métodos de factores humanos descritos en este libro hasta ahora son útiles para desarrollar y documentar una comprensión detallada del entorno de uso.

En preparación para la ejecución de una prueba de usabilidad exitosa hay varios elementos clave que deben organizarse de antemano:

• Tareas de prueba

• Escenarios de prueba

• Script de prueba

80

• Introducción a los participantes

• Entrenamiento de participantes

• Encuesta de diseño

• Herramientas de documentación de datos

• Configuración del espacio de prueba

• Personalización de la tecnología

• Prueba piloto

• Reclutamiento de participantes

Aunque puede parecer desalentador preparar cada uno de estos elementos, todos son importantes para asegurar que su prueba de usabilidad se ejecute sin problemas y que obtenga el máximo provecho del tiempo invertido en las pruebas. Si la preparación de estos ítems se ha hecho bien, la ejecución de la prueba de usabilidad será relativamente sencilla y los datos recopilados destacarán el nivel de seguridad y eficacia que puede esperar ver de cada sistema o proceso evaluado cuando se implementan. El resto de esta sección describirá cómo preparar cada uno de los elementos necesarios para ejecutar un exitoso test de usabilidad.

Sección 8.5.1. Identificar las tareas a incluir en una prueba de usabilidad

Identificar qué tareas incluir en una prueba de usabilidad es una decisión importante. Si se omiten las tareas que tienen el potencial de resultar en riesgos de seguridad, la prueba no revelará la gama completa de problemas que resultarán de la implementación de la tecnología o cambio de proceso.

En una situación ideal, se llevará a cabo un análisis de tareas (Capítulo 6) sobre la tecnología o proceso para identificar un conjunto completo de tareas desde las cuales seleccionar un subconjunto para incluir en la prueba de usabilidad. Deben seleccionarse las tareas que son:

Tareas primarias o de rutina realizadas en el dispositivo; para identificar los

problemas que se producirán con frecuencia y en última instancia conducir a la

frustración del usuario y la adopción deficiente de la tecnología o el proceso.

Tareas críticas de seguridad (es decir, tareas que si se ejecutan incorrectamente

tendrán un impacto negativo directo en el paciente.) Ver debilidad de punto único

en el Capítulo 9.5.6.1); Para identificar problemas de seguridad.

Tareas asociadas a violaciones heurísticas identificadas en un análisis heurístico

(Capítulo 7); Para identificar problemas de seguridad y usabilidad.

Independientemente de si se lleva a cabo o no un análisis formal de la tarea, los siguientes son útiles para identificar las tareas que cumplen los criterios enumerados anteriormente:

81

Datos de observación,

Grupos focales, entrevistas y resultados de encuestas,

Resultados del análisis heurístico

Datos de incidentes pasados (tanto de su propia organización como de otras

organizaciones que publican datos de incidentes).

Dependiendo del tiempo de prueba disponible para cada participante (no debe exceder las 3 horas), es posible que sea necesario recortar el conjunto de tareas incluidas en los escenarios en función de la prioridad relativa de cada tarea (por ejemplo, la importancia crítica de la tarea, la ubicuidad de la tarea, o cuan problemática se espera que sea la tarea, con base en los resultados de otros métodos de factores humanos, como el análisis heurístico).

Sección 8.5.2. Diseño de escenarios de prueba de usabilidad

Un escenario de prueba de usabilidad es similar a una escena en un guion de película. Es el contexto o la historia la que proporciona la motivación para lo que está a punto de suceder. En el caso de la prueba de usabilidad, es el contexto clínico el que proporciona la motivación para que el participante realice una serie de tareas. Los escenarios de prueba de usabilidad se basan en observaciones, entrevistas, grupos focales y encuestas, así como en cualquier análisis de tareas o análisis heurísticos que se hayan completado.

Dependiendo del número, el tipo y la complejidad de las tareas que se están probando, se puede requerir más de un escenario en una sola sesión de pruebas de usabilidad.

Para crear sus escenarios de prueba, es útil comenzar creando una hoja de resumen de usabilidad o un esquema para cada grupo de usuarios único que interactuará con la tecnología (consulte la Figura 13). La hoja de resumen debe incluir lo siguiente:

quién es el grupo de usuarios,

sus objetivos asociados con la tecnología,

las tareas que tendrían que realizar para lograr cada uno de esos objetivos,

cualquier equipo suplementario o de apoyo que se necesitaría, y en qué

ambiente(s) se completan esas tareas.

82

Figura 13. Ejemplo de una hoja de resumen para un estudio de usabilidad de bombas electrónicas inteligentes.

A continuación, puede utilizar estos esquemas para crear escenarios que incluirán las tareas y los entornos para cada tipo de usuario (consulte el ejemplo en la Figura 14). Cada escenario debe describir lo siguiente:

Grupo de usuario

Escenario (historia)

Configuración del entorno

Ajustes iniciales (p. ej., Los ajustes iniciales ya se han programado antes de iniciar

el escenario)

Tareas

Errores plantados (opcional)

Un representante clínico de cada grupo de usuarios debe ayudarle a desarrollar y luego revisar sus escenarios, para asegurarse de que son lo más realistas posible.

83

Cuando se prueban tecnologías o se proponen cambios en el sistema, puede ser extremadamente valioso considerar si las personas son más capaces de recuperarse de errores de uso común y modos de falla usando la nueva tecnología o enfoque. Para examinar esto durante una prueba de usabilidad, los errores se pueden plantar en los escenarios que cree para poder observar si, y cómo, los participantes se recuperan de los errores si se detectan en el escenario. Los errores comunes que se pueden plantar son cosas como el paciente incorrecto, un problema con los 5 parámetros básicos, etc., pero los errores específicos que elija plantar dependerán de lo que está probando y por qué lo está probando.

Normalmente, se tendrán que desarrollar múltiples escenarios para una sola prueba de usabilidad. Las principales razones de esto incluyen (1) tener en cuenta los diferentes grupos de usuarios, (2) realzar el realismo y reducir la fatiga de los participantes cuando muchas tareas deben ser evaluadas, y (3) el contrapeso para minimizar los efectos del aprendizaje. Las dos primeras razones se describirán aquí.

La tercera razón se discutirá en la Sección 8.8 Pruebas comparativas de usabilidad.

(1) Tener en cuenta los diferentes grupos de usuarios

Cuando la tecnología o el proceso que se utiliza para probar la usabilidad afectan a múltiples grupos de usuarios, es importante diseñar escenarios específicos para cada grupo de usuarios, teniendo en cuenta las metas y las tareas resultantes desde la perspectiva de cada grupo. Por ejemplo, una enfermera y un farmacéutico pueden interactuar con una bomba inteligente, pero lo harán desde diferentes perspectivas y con diferentes objetivos y tareas asociadas (por ejemplo, programar una bomba para administrar medicamentos a un paciente versus actualizar los límites duros y suaves de la biblioteca de fármacos para un área clínica). Como resultado, deben diseñarse escenarios de usabilidad adaptados para que cada grupo de usuarios pueda realizar tareas relevantes y representativas durante las pruebas.

(2) Mejorar el realismo y reducir la fatiga de los participantes

Cuando hay muchas tareas para probar, se recomienda encarecidamente que se distribuyan a través de una serie de escenarios en lugar de que todos se incluyan en una larga historia clínica. En muchos contextos clínicos, el personal debe realizar múltiples tareas, la transición entre los diferentes pacientes, las tareas y las áreas dentro del hospital. Su sesión de usabilidad debe configurarse de manera similar para que los participantes puedan pasar de un paciente a otro, completando una tarea o un grupo de tareas a medida que avancen. Aunque la duración del escenario variará dependiendo de los tipos de tareas que se están completando y cuánto tiempo los participantes individuales necesitan para completar cada tarea, una sesión de usabilidad completa no suele exceder de aproximadamente 2,5 horas de duración y muchas pueden hacerse en períodos de tiempo mucho más cortos. Romper este tiempo total en escenarios más cortos les proporciona a los participantes la oportunidad de tomar un rápido descanso mental y recargar antes de comenzar con el siguiente conjunto de tareas.

84

Figura 14. Escenario para que la enfermera de cuidados intensivos apoye la prueba de usabilidad de una bomba de infusión (Continúa en la siguiente página)

Escenario 1

Grupo de usuarios: Enfermeras de la UCI

Historia: Dos pacientes de la UCI que son atendidos por una enfermera necesitan los medicamentos prescritos. El paciente 1 necesita un antibiótico administrado como una infusión secundaria y el paciente 2 necesita un bolo de morfina IV. Mientras se administra el bolo de morfina la enfermera es interrumpida por una bomba que da señal de alarma en el otro paciente.

Configuración del entorno:

Entorno de simulación de cuidados intensivos.

La enfermera participante cuidará a 2 pacientes.

Dos camas para pacientes separadas por una cortina.

Mesa pequeña al lado de cada cama

Mesa y silla entre los pies de ambas camas para las actividades de registro de la enfermera

Hoja de flujo y Kardex para cada paciente en la tabla de registros.

La tabla de pacientes está en el soporte en la parte inferior de cada cama

El paciente 1 tiene un polo intravenoso en el lado izquierdo del paciente con una bomba IV de

triple canal conectada.

El paciente 2 tiene un soporte de IV en ambos lados del paciente con una bomba IV de triple

canal conectada a cada soporte de IV.

Un actor desempeña el papel de Paciente 1

Se utiliza un maniquí para el Paciente 2

El paciente 1 está conectado a un monitor; el paciente 2 no lo está.

Los siguientes medicamentos están funcionando en el Paciente 1:

o Salina normal funcionando como una infusión primaria a 30 ml / h,

o Norepinefrina funcionando como infusión primaria a 7 mcg / h

Los siguientes medicamentos están funcionando en el Paciente 2:

o La morfina funciona como una infusión primaria a 5 mg / h.

Los medicamentos adicionales y los suministros necesarios para más adelante en el escenario están en un carrito hacia el lado derecho del área de prueba.

o 3 bolsas de solución salina IV

o Ceftriaxona IV

o Toallitas de alcohol

o Tubos IV primarios

o Tubos secundarios IV

o Conectores de tubería IV de múltiples puertos

o Etiquetas de fecha de la tubería IV

o Medicamentos añadidos

o jeringa de lavado con solución salina de 10 ml (x3)

85

(3) Contrapeso para minimizar los efectos del aprendizaje

Cuando un estudio de usabilidad está compuesto de múltiples escenarios independientes, el orden en que los participantes completan cada uno de los escenarios debe ser rotado entre los participantes para reducir los efectos de aprendizaje. Esto se conoce como contrapeso. Por ejemplo, si cada participante realiza siempre la tarea 2 correctamente después de completar la tarea 1, es difícil saber si esto se debe a que la tarea 2 es menos propensa a errores que la tarea 1, o si los participantes aprendieron de la tarea 1 y pudieron mejorar su tarea antes de completar la tarea 2.

Además de contrarrestar los escenarios, los errores plantados dentro de los escenarios también deben compensarse para minimizar los efectos de aprendizaje.

Ajustes iniciales:

El paciente 1 tiene dos infusiones primarias:

1. Salina normal a 30 ml / h

2. Norepinefrina a 7 mg / kg / h.

La infusión de norepinefrina está casi vacía y el volumen a infundir se programa a 2 ml

para que la bomba alarme durante la programación del bolo de morfina en el Paciente

2.

Ambos pacientes tienen un catéter de línea central de 3 lúmenes

El paciente 2 tiene una infusión primaria:

1. La infusión de morfina (1 mg / ml) a 0,5 mg / h

El monitor está indicando que la Presión Arterial Media del Paciente 1 es 50.

Los pedidos de mediación incluidos en las tablas son consistentes con los conjuntos de

órdenes usados en nuestra unidad de cuidados intensivos.

Tareas (en orden):

Paciente 1:

Configure la infusión IV secundaria

Programar la infusión IV secundaria utilizando una biblioteca de fármacos

Paciente 2:

Programar un bolo de morfina por vía intravenosa utilizando la función de bolo de

la bomba

Errores plantados:

La morfina se infunde a 0,5 mg / h, pero debe ser de 5 mg / h. Ver si se detecta

cuando se administra la dosis en bolo.

86

Sección 8.5.3. Diseño de guiones de usabilidad

Para cada escenario desarrollado, se necesita un guion de prueba de usabilidad. Un guión contiene el diálogo y las instrucciones para el facilitador y los actores que participan en los escenarios necesarios para guiar a los participantes a través de cada escenario. También incluye otras indicaciones y señales en el entorno que son necesarias para iniciar tareas para los participantes (p. Ej., Alarmas de tecnología, cambios en la condición del paciente reflejados en el monitor, páginas aéreas).

Un extracto de un guion de usabilidad para el ejemplo de la Figura 14 se muestra en la Figura 15 a continuación.

[Enfermera Actor] "Hola, ________________ un placer conocerle! Debe de ser nuestra enfermera de rotación. Mi nombre es ________________ y yo soy la educadora de enfermería en la sala y también estoy trabajando en la cabecera de hoy porque estamos cortos de personal. Lo que me ayudaría es si tú y yo pudiéramos trabajar juntas para cuidar a mis dos pacientes ya que ambos son bastante inestables. Ambos son nuevos ingresos a nuestra unidad y ambos necesitan medicamentos administrados. Ya que no has trabajado en esta unidad antes, hay un par de cosas que te mostraré antes de presentarte a nuestros pacientes. Primero, aquí está nuestro carro de la administración de la medicación donde puede encontrar la historia del paciente y las órdenes de medicación. Necesito que seas responsable de administrar los medicamentos IV, y yo me encargaré de cualquier documentación ".

Está bien, ¿estás lista para ser presentado a tu primer paciente? "

[Participante] "Sí"

[Actor de enfermera] "Genial! Empecemos. Nuestra primera paciente e s la Sra. Katharine Tuer. Ella fue admitida ayer después de llegar al departamento de emergencia porque tenía dificultad para respirar. Sufre de enfisema y trastorno por reflujo, y desde su ingreso, sospechamos que también ha contraído una infección respiratoria. Tiene 88 años y 54 kg.

Ella tiene una línea de mantenimiento, pero tenemos que iniciar la ceftriaxona para su sospecha de infección respiratoria. Su historial de paciente, orden de medicamentos, ceftriaxona, y todos los suministros que necesitará están en el carro allá. Mientras haces eso, voy a ir a ver a la Sra. Sillian.

[Enfermera Actor] Mientras que el participante está instalando las infusiones de la señora Tuer, ponga las bolsas IV y para la infusión de la Sra. Sillian sobre la mesa junto a su cama.

87

Figura 15. Extracto del guión de usabilidad para la prueba de usabilidad que compara dos bombas de infusión

Sección 8.5.4. Diseño de herramientas para documentación de datos

La documentación es una de las tareas más importantes durante una prueba de usabilidad. Es importante que capture tantos datos como sea posible en tiempo real durante las pruebas porque revisar secuencias de vídeo para extraer sus datos es extremadamente lento. Los escenarios de usabilidad finalizados se utilizarán como base para cualquier herramienta de documentación de datos que cree. No existe un método oficial para documentar los datos de prueba de usabilidad, pero generalmente se recomienda un formato computarizado de hoja de cálculo con las tareas y las métricas listadas para cada escenario en la prueba de usabilidad. Para cada tarea es útil capturar si han completado satisfactoriamente la tarea (por ejemplo, pasar / fallar) y escribir notas de estilo libre sobre las dificultades o comentarios que hicieron, que sean relevantes para la usabilidad. Los criterios de aprobación / reprobación deben establecerse con antelación. Uno de los criterios de aprobación / reprobación debe ser el tiempo de la tarea (por ejemplo, si un participante tarda más de 5 minutos en completar esta tarea, reprueba la tarea, ya que esto dará lugar a una consecuencia inaceptable para el paciente) o el número de solicitudes de asistencia antes

________________________________________________________________________________________

Orden: Nombre del Fármaco: Ceftriaxone

Concentración: 1 g / 10 ml

Orden: 2 g en 100 mL de SN, infundir durante 2 horas

Programación: Velocidad: 50 mL / h

VTBI: 100 mL.

Duración: 2 horas

Participante: Lea el pedido de medicación

Verifique los cinco parámetros básicos

Cuelgue ceftriaxone

Seleccione una infusión intermitente (es decir, secundaria)

Entrar en la biblioteca de drogas

Seleccione ceftriaxone

Programe la bomba de programa:

Velocidad = 50 mL / h, VTBI = 100 mL

Conecte al puerto por encima de la bomba

[Enfermera Actor] "Muy bien, eso es genial! Gracias por su ayuda con eso. Ven acá y te presentaré a la señora Sillian "...

88

de poder completar la tarea. Si las tareas se realizan en un orden que no se esperaba, esto también debería estar documentado en las notas.

Cuando se usa un computador, la capacidad de agregar un sello de tiempo de cuando se realiza cada tarea (o cuando se experimentaron dificultades) puede ser muy útil, especialmente para determinar el orden de las tareas, y cuánto tiempo tomaron los participantes para completar varias las tareas. Algunos programas informáticos de hoja de cálculo proporcionan métodos abreviados de teclado que permiten capturar una marca de tiempo en una celda de hoja de cálculo. Dependiendo del número de participantes y el propósito de su prueba de usabilidad, es posible que desee tener una sola hoja de documentación de datos por participante, o puede que desee tener una sola hoja de cálculo para todos los participantes.

Un ejemplo de hoja de cálculo para documentación de datos se puede encontrar en la Tabla 5.

Sección 8.5.5. Configuración del espacio de prueba

La ubicación física elegida para las pruebas de usabilidad dependerá de los recursos disponibles. Las pruebas de usabilidad a menudo se ejecutan en (1) laboratorios de simulación, (2) entornos clínicos desocupados, (3) una oficina vacía, habitación o pasillo. Si no tiene acceso a un laboratorio de simulación, casi cualquier entorno puede convertirse en un espacio de prueba de usabilidad apropiado. Un estudio de usabilidad puede ejecutarse con éxito sin tener acceso a un laboratorio formal de simulación.

Sección 8.5.5.1 Laboratorio de simulación

Si tiene acceso a un laboratorio de simulación, esta es una excelente opción para ejecutar sus sesiones de usabilidad. Generalmente, un verdadero laboratorio de simulación tiene tanto una sala de pruebas como una sala de observación. La sala de pruebas es donde se lleva a cabo la sesión de prueba de usabilidad. La tecnología, o el cambio del sistema que se está probando, se colocan en la sala de pruebas junto con cualquier objeto, equipo, etc. El participante y cualquier otro actor permanecen en la sala de pruebas para completar la prueba de usabilidad. La sala de observación es donde el facilitador se sienta para observar y documentar lo que sucede durante la prueba de usabilidad. Algunas instalaciones disponen de equipo de grabación de audio y video en la sala de observación y un espejo o vidrio unidireccional que separa la sala de pruebas de la sala de observación. Esta barrera física entre el facilitador y el participante significa que la distracción no intencional puede ser minimizada, manteniendo al participante centrado en las tareas a mano.

Sección 8.5.5.2 Entorno clínico desocupado

Si tiene acceso a un entorno clínico desocupado que coincida con el tipo de entorno que se simula, también es una excelente opción para una prueba de usabilidad. Un ejemplo sería una sala de habitación / cama vacía. Asegúrese de tener permiso para utilizar el espacio, así como cualquier material para la sesión. Configure la tecnología o el cambio del sistema que se va a probar, junto con cualquier otro equipo y suministros en el entorno clínico desocupado. En cuanto a la documentación de sus observaciones durante la sesión, es poco probable que este tipo de espacio tendrá una barrera física, por lo que el documento durante

89

la sesión de prueba, asegúrese de ser lo más silencioso posible. Siempre que sea posible, configure una cámara de video para grabar cada sesión. Idealmente, utilice un trípode o una superficie estabilizadora que le permita tomar notas durante la sesión o que alguien más cuide de la grabación de vídeo mientras observa y toma notas.

Sección 8.5.5.3 Oficina vacía, habitación o pasillo

Si no tiene acceso a un laboratorio de simulación o un entorno clínico desocupado, cualquier sala donde no se proporciona atención al paciente se puede configurar para ayudarle a recopilar datos valiosos a través de pruebas de usabilidad. Si puede, pida prestado equipo como camas de hospital, monitores fisiológicos, bombas de infusión, suministros, etc. para hacer que el ambiente sea lo más realista posible.

Sección 8.5.6. Grabación de la sesión

Si puede grabar vídeo y audio en cada sesión de prueba de usabilidad, puede ser un recurso valioso para apoyar el análisis de sus datos de prueba de usabilidad y para ayudar a comunicar sus hallazgos a otras personas. Durante un escenario de prueba de usabilidad, las cosas tienden a suceder rápidamente, y puede ser difícil de capturar y absorber todo lo que sucede en tiempo real, incluso si tiene una buena herramienta de documentación de datos. Saber que usted tiene la capacidad de volver a una grabación video para repasar o para confirmar algo que usted vio puede proporcionar una cierta paz de la mente. Sin embargo, como se señala en la Sección 8.6.3, todavía es importante capturar tantos detalles sobre la sesión como sea posible en tiempo real usando su herramienta de documentación de datos, porque basarse en imágenes de video como el único medio de recolección de datos aumentará significativamente el tiempo requerido para analizar. Las grabaciones de vídeo deben utilizarse como una copia de seguridad de observaciones en tiempo real y documentación solamente.

Considere la posibilidad de utilizar múltiples grabadores de vídeo y audio para capturar la prueba de usabilidad desde diferentes ángulos, ya que puede ser difícil de capturar la imagen más grande y tareas más detalladas como la programación de la bomba de una sola cámara. Tener a alguien a cargo de filmar la sesión puede mejorar la calidad del vídeo y de audio, ya que pueden mover, panoramizar y ampliar las cámaras de vídeo según sea necesario. El uso de trípodes para cada cámara puede soportar la flexibilidad de la colocación de la cámara., o equipo de grabación de lujo, o avanzado no es necesario para capturar una prueba de usabilidad en la película. Una cámara de vídeo estándar, o incluso una cámara de teléfono celular, a menudo puede ser suficiente.

Una prueba de usabilidad del piloto (Sección 8.6.12) le ayudará a determinar la mejor colocación de la cámara para un vídeo y audio óptimos. Antes de ejecutar cada sesión de prueba de usabilidad, asegúrese de tener el permiso del participante para grabar vídeo y audio de la sesión.

90

Sección 8.5.6.1 Otras consideraciones de instalación

Algunos elementos adicionales que puede que desee considerar la preparación para su espacio de prueba de usabilidad incluyen:

Un espacio designado para que los participantes almacenen sus pertenencias (por

ejemplo, teléfonos, bolsas, bebidas)

Un área separada para el entrenamiento de los participantes si se están realizando

sesiones de capacitación y usabilidad para diferentes participantes al mismo

tiempo

Boligrafos, papel y una calculadora para los participantes si hay cálculos o

encuestas incluidas en su prueba de usabilidad

Tabla 5. Hoja de cálculo para la documentación de datos capturados en pruebas de usabilidad en tiempo real.

91

Sección 8.5.7. Personalización de la tecnología

Si se está probando una tecnología específica (en contraposición a un proceso), deberá asegurarse de que todos los ajustes se han adaptado a las necesidades de los escenarios y que coincidan con los ajustes ideales para la instalación o la unidad donde se va a utilizar la tecnología. Si se está evaluando la nueva tecnología, tendrá que trabajar con expertos clínicos y otras partes interesadas para determinar qué parámetros son los más apropiados para cada unidad clínica de interés. Si no es posible determinar todos los ajustes y valores adecuados antes de las pruebas de usabilidad, quizás desee considerar utilizar los ajustes de fábrica para obtener una imagen realista. Alternativamente, cambiar los ajustes para que sean muy sensibles (para activar alarmas y solucionar problemas posteriores), o por lo tanto no son sensibles en absoluto (para ocultar problemas potenciales) pueden proporcionar una visión de los peores escenarios.

Sección 8.5.8. Creación de una introducción de un participante

Hacer que los participantes se sientan cómodos durante una prueba de usabilidad es tan importante, si no más, que el diseño de los mismos escenarios de prueba de usabilidad. Si los participantes se sienten cómodos durante una prueba de usabilidad, es más probable que terminen la prueba y tomen el tiempo para proporcionar retroalimentación significativa. También son más propensos a ser voluntarios como participantes para una prueba de usabilidad futura.

La manera en que una prueba de usabilidad se introduce a un participante puede ser muy importante en hacer que un participante se sienta a gusto. Para apoyar una introducción adecuada y acogedora para los participantes, se recomienda encarecidamente que el profesional de la tecnología biomédica tome el tiempo necesario para preparar un guión que cubra:

Una introducción a la persona que dirige la sesión

Una introducción al proyecto y / o metas de pruebas de usabilidad

Una visión general del proceso y el propósito de la prueba de usabilidad

Una estimación de cuánto tiempo se espera que dure la sesión

Una explicación de que el participante puede tomar pausas o detener la prueba de

usabilidad completamente en cualquier momento sin experimentar ninguna

consecuencia negativa

Una explicación de que es la tecnología, y no el participante, la que está siendo

probada

Una explicación de que los datos recogidos serán tratados como estrictamente

confidenciales (Apéndice A) y que los resultados no serán compartidos con el

supervisor de los participantes u otros

En la Figura 16 se muestra un ejemplo de texto de introducción, basado en los escenarios de usabilidad y la secuencia de comandos de la Figura 15.

92

Un elemento clave a incluir en la introducción de una prueba de usabilidad es la solicitud de pedir a los participantes que piensen en voz alta mientras están trabajando. Esto se conoce como el protocolo de pensar en voz alta. Cuando los participantes piensan en voz alta, proporciona al profesional o facilitador de tecnología biomédica una idea de por qué un participante hizo algo de determinada manera. Esta información le ayuda a determinar si la tecnología o el diseño del sistema coincide con el modelo mental de un participante y si los errores o casi errores durante las pruebas se deben a problemas de diseño o falta de conocimiento y comprensión.

Introducción general

"Hola Mary, es un placer conocerte. Soy John, y soy ingeniero clínico aquí en el hospital. Gracias por participar en este test de usabilidad de las bombas de infusión inteligentes. Antes de empezar, te daré información básica sobre por qué estás aquí y luego te explicaré lo que vamos a hacer como parte de la sesión. Siéntase libre de detenerme en cualquier momento para hacer preguntas a lo largo del camino.

Nuestro hospital va a comprar nuevas bombas de infusión inteligentes, pero antes de tomar una decisión sobre qué modelo comprar, queremos probar lo que está disponible para asegurarnos de que el que elegimos le apoya en hacer su trabajo de manera segura, eficiente y eficaz. Desafortunadamente, no hay una bomba inteligente perfecta, y por lo tanto hoy haremos pruebas de usabilidad en tres opciones diferentes para ayudar a identificar cuál funcionará mejor para nuestro hospital y qué cambios a otros elementos del sistema pueden ser necesarios para apoyar su uso más seguro posible.

Las pruebas de usabilidad son un método que usamos para probar tecnologías con usuarios reales como tú. Observamos mientras usas la tecnología para ver si hay problemas de diseño o de usabilidad que causan problemas. Cuando podemos identificar los problemas de diseño y usabilidad desde el principio, podemos decidir comprar otra bomba, o elaborar estrategias de mitigación para tratar de evitar que estos problemas sucedan en el hospital.

Realmente quiero enfatizar que el propósito de la prueba de usabilidad no es evaluar tus habilidades o desempeño, y no afectará a tu posición en el hospital de ninguna manera. Si experimentas algún problema mientras usas las bombas, no es un reflejo de tus habilidades, sino más bien una indicación de que la tecnología no está satisfaciendo tus necesidades. Eres nuestro experto, y estamos aquí para aprender de tí. Si tienes dificultades para usar una bomba, indica un problema de diseño de tecnología o de usabilidad que probablemente será experimentado por sus colegas.

¿Tiene alguna pregunta hasta ahora?

93

Figura 16. Guion introductorio para la prueba de usabilidad que compara dos bombas de infusión

Explicación del proceso de consentimiento informado

"Lo primero que te pediré que hagas es firmar un formulario de consentimiento. El formulario de consentimiento explica que tu participación en este estudio de usabilidad es completamente voluntaria y que eres libre de dejar de participar en cualquier momento sin ningún impacto para tío tu empleo aquí en el hospital. Además, todo lo que suceda durante la sesión de prueba de usabilidad se mantendrá confidencial, con todos los datos, incluyendo cualquier realimentación o comentarios que compartas con nosotros, nunca se vincule a su nombre real. Ahora, te daré tiempo para leer y firmar el formulario de consentimiento, pero si tienes alguna, pregunta por favor no dudes en hacerla."

Explicación del proceso de prueba de usabilidad

"Gracias por completar el formulario de consentimiento. Ahora te daré una visión general de cómo se ha establecido esta prueba de usabilidad. Estaremos probando dos bombas de infusión inteligentes diferentes hoy en día, y para cada una de esas bombas, pasaremos por cuatro pasos principales. Primero le daré una breve formaciónen la bomba, luego te pediré que cumplimentes una encuesta sobre su experiencia y entrenamiento relacionado con la tecnología de bombas inteligentes, en tercer lugar serás guiado a través de una serie de escenarios clínicos con la bomba, y finalmente, te pediré que complete una encuesta para compartir tus pensamientos y cualquier comentario sobre la bomba inteligente. Luego repetiremos los cuatro pasos de nuevo para la segunda bomba de infusión inteligente.

Después de que hayas terminado el entrenamiento y la primera encuesta, te presentaré a nuestra enfermera confederada (actor) que estará aquí en la habitación contigo para ayudar a guiarle en cada escenario. Si tienes alguna pregunta, puedes preguntarle. Podría ocurrir, que si le haces una pregunta ella responderá preguntándole qué harías normalmente en tu propia unidad o qué piensas que debe ser hecho. Esto no es ser condescendiente, es porque estamos genuinamente interesados en aprender lo que harías si te enfrentara con esa misma pregunta o desafío en la realidad.

Por último, a medida que avance en los escenarios clínicos, si puedes pensar en voz alta en términos de lo que estás haciendo, esto puede ser extremadamente enriquecedor para nosotros. Así, por ejemplo, si estabas verificando una etiqueta de medicamento, podrías decir: "Ok, veo la etiqueta del medicamento dice Smith, 20 de febrero de 1954, así que ahora estoy revisando la pulsera del paciente, y veo que es el Sr. Smith y su cumpleaños es en febrero 20, 1954. Eso coincide, así que puedo seguir adelante y establecer su infusión. "

¿Tienes alguna pregunta?"

94

Sección 8.5.9. Diseño de Entrenamiento

Los participantes deben recibir capacitación antes de realizar una prueba de usabilidad para asegurar que todos los participantes tengan el mismo nivel básico de conocimiento y comprensión de la tecnología, o el cambio del sistema, antes de que empiece la prueba. Una excepción a esto es cuando se prueba la usabilidad de un dispositivo en el que se espera que los usuarios finales usen el dispositivo sin ningún entrenamiento (por ejemplo, un desfibrilador externo automático). En estos casos no se debe proporcionar capacitación para asegurar que la experiencia del usuario sea representativa de las condiciones posteriores a la implementación del dispositivo o proceso.

La capacitación debe ser entregada a los participantes de una manera realista, lo que significa que la duración, el formato y la profundidad del contenido presentado durante el entrenamiento de prueba de usabilidad debe coincidir con lo que sería proporcionado por el proveedor durante el proceso de implementación. El contenido de la capacitación debe cubrir todas las tareas que serán evaluadas durante la sesión de prueba de usabilidad y debe ser consistente entre los participantes para asegurar que cada sujeto tenga el mismo nivel de conocimiento básico. Idealmente, los participantes deben ser entrenados 48 horas o más antes de la prueba para permitir que se produzca cierta degradación de la formación natural [36], aunque esto es a menudo difícil de programar.

Aunque la formación debe ser comparable a la formación proporcionada porel proveedor, un proveedor no debe proporcionarlo. Esto se debe a que un proveedor puede no proporcionar toda la información requerida consistentemente entre todos los participantes y puede no proporcionar capacitación específica para las tareas de la prueba de usabilidad. Idealmente, al desarrollar materiales de capacitación para una prueba de usabilidad, el profesional de tecnología biomédica, o facilitador de la prueba de usabilidad, recibiría capacitación del proveedor y, a continuación, desarrollaría un programa de capacitación para las pruebas de usabilidad que es comparable en longitud y amplitud e incluye todo el contenido necesario para llevar a cabo las tareas de la prueba de usabilidad. Si los participantes ya están bastante familiarizados con la tecnología específica o el cambio de sistema que se está probando (por ejemplo, ya está en uso en su unidad), la capacitación puede no ser necesaria en absoluto.

Sección 8.5.10. Diseño de encuestas de prueba de pre y post usabilidad

Como parte de la mayoría de las pruebas de usabilidad, usted querrá diseñar y realizar encuestas tanto antes como después de la prueba de usabilidad en sí. El propósito de estas encuestas es recolectar información acerca de (1) que tan representativos son sus participantes con respecto a la población real de usuarios, y (2) sus percepciones de la tecnología o cambio de sistema que se están probando.

Sección 8.5.10.1 Encuesta de Pruebas de Pre-usabilidad

La encuesta pevia (Figura 17) generalmente se divide en dos partes para recopilar información sobre: demografía (por ejemplo, edad, número de años de experiencia, área clínica de experiencia, entrenamiento previo en dispositivos similares); y el nivel de

95

conocimiento de fondo relacionado con la tecnología o el cambio del sistema que se está probando.

La información demográfica es útil para tener una idea de si su grupo de participantes es representativo de la mayor población de usuarios. Si su grupo de participantes de prueba no es demográficamente representativo de la población más grande, es posible que no observe la gama completa o la frecuencia de los problemas que podrían esperarse en la población general de usuarios durante las pruebas de usabilidad.

La recopilación de información sobre el nivel de conocimientos básicos también es útil para entender la comprensión básica de los participantes relacionada con la tecnología o el cambio del sistema que se está probando, especialmente si su grupo de participantes es representativo de la población general. Realizar esta encuesta antes de la sesión de entrenamiento y luego observar como los participantes completan cada escenario después de la sesión de entrenamiento puede ayudar a establecer la efectividad de la capacitación. Si varios participantes no obtienen los conocimientos necesarios para completar los escenarios de prueba durante la sesión de capacitación, pueden señalar la necesidad de revisar el contenido y la entrega del entrenamiento, o diseñar problemas con la tecnología que se está probando.

96

Figura 17. Muestra de preguntas sobre demografía, conocimiento y experiencia como parte de una encuesta de pre-usabilidad

Datos Demográficos

1. Cómo se describe mejor su papel en el hospital?

Enfermera registrada de tiempo completo

Enfermera registrada de tiempo parcial

Oto:_________________

2. Cuál e su edad?

18 – 29 años

30 – 39 años

40 - 49 años

50 - 64 años

65 años o más

3. Hace cuánto es una enfermera registrada?

Menos de un año

1 a 4 años

5 a 9 años

10 a 20 años

Más de 20 años

4. En que unidades trabaja habitualmente? (identifique todas las que apliquen)

Consulta Externa

Emergencia

Cirugía

Unidad Pediátrica de Cuidado Intensivo

Unidad Neonatal de Cuidado Intensivo

Unidad Quirúrgica de Cuidado Intensivo

Unidad de Cuidado Post-anestesia

Otra:______________

5. Cuánto hace que trabaja en el área clínica en que está ahora?

Menos de un año

1 a 4 años

5 a 9 años

10 a 20 años

Más de 20 años

Conocimiento y Experiencia

1. Conóce una bomba de infusión inteligente?

Si

No

2. Ha usado una bomba inteligente antes?

Si

No

No estoy segura

3. Qué es el límite de bombeo de una bomba inteligente?

Una característica del equipo para restringir los parámetros

de programación que caen fuera de la ventana de seguridad

Una característica del equipo para verificar si los usuarios

desean programar la bomba usando los parámetros que han

seleccionado

Una característica de software para restringir los parámetros

de programación que caen fuera de la ventana de seguridad

Una característica de software para verificar si los usuarios

desean programar la bomba usando los parámetros que han

seleccionado

No estoy segura

4. Ha recibido alguna vez entrenamiento para usar una bomba de infusión inteligente?

Si

No

No estoy segura

5. En general, cuál es su método preferido para aprender a utilizar un dispositivo médico? (Califique de 1 a 6, siendo 1 la más preferida y 6 la menos preferida)

Leer acerca del dispositivo

Asistir a una demostración práctica

Asistir a una conferencia o seminario

Tener acceso al dispositivo para practicar por si misma y

luego hacer preguntas según sea necesario

Trabajar lado a lado con un colega experto

Ver un video de entrenamiento

97

Sección 8.5.10.2 Encuesta sobre la prueba de post-utilidad

La encuesta posterior (Figura 18) se lleva a cabo para recopilar las percepciones de los participantes y la retroalimentación sobre la tecnología o el cambio del sistema que se está probando. Este tipo de datos es útil para entender las opiniones de los participantes, el nivel de confianza y las preocupaciones de seguridad y flujo de trabajo al utilizar el dispositivo o interactuar con el cambio del sistema. Aunque esta información es valiosa, recuerde que las percepciones y preferencias de los participantes de una tecnología están influenciadas por muchos factores y nunca deben prevalecer sobre los datos reales de rendimiento de los usuarios, recopilados a través de las pruebas de usabilidad (ver Sección 5.1 Paradoja de Desempeño vs Preferencia). Cuando los participantes confían en sus habilidades para usar una tecnología, pero no funcionan bien en la realidad, a menudo señala un diseño deficiente de la tecnología.

Sección 8.5.11. Reclutamiento de participantes

Los participantes en las pruebas de usabilidad son parte integral de cualquier prueba de usabilidad. Los participantes deben ser representativos de la gama de usuarios finales de la nueva tecnología o cambio de sistema que se está probando en términos demográficos, conocimientos y experiencia, y área de especialización clínica. Cuando se incluye una gama de usuarios finales representativos como parte del proceso de prueba de usabilidad (por ejemplo, médicos, enfermeras y farmacéuticos), los datos generados serán más amplios, representativos y beneficiosos para el proceso de evaluación, ya que diferentes problemas serán descubiertos por diferentes tipos de usuarios finales.

Sección 8.5.11.1 Elegibilidad

Para asegurarse de que los participantes son representativos de la población de prueba deseada, debe establecerse una lista de criterios de elegibilidad para ayudar con el proceso de reclutamiento. Los criterios de elegibilidad deben definir las características deseadas de sus participantes, tales como el número de años de experiencia que tienen, o sus credenciales profesionales. Los criterios de exclusión también pueden definirse como parte de su definición de elegibilidad. Las personas interesadas en participar que no cumplan con los criterios de elegibilidad no deben ser incluidas en la prueba de usabilidad real, sin embargo, podrían ser incluidas como participantes en la prueba de usabilidad del piloto (Sección 8.5.12), o como participantes en una nueva usabilidad prueba.

Sección 8.5.11.2 Participación y reembolso del personal

La participación del personal en una prueba de usabilidad suele establecerse en una de dos maneras, ya sea que el personal participe en la prueba durante las horas de trabajo si éste puede ser sustituido durante el tiempo de la prueba de su puesto de trabajo o que el personal participe en la prueba después de las horas de trabajo y se compense su tiempo. Idealmente, cuando una organización de salud está planeando implementar la nueva tecnología o cambio de sistema que está siendo probado, la posición de un participante debe ser rellenada para que puedan participar en las pruebas durante las horas de trabajo. Sin embargo, si esto no es posible, los participantes deben ser compensados por su tiempo fuera de las horas de trabajo. Considere el uso de tarjetas de regalo como un medio de compensar

98

a los participantes si la institución no es capaz de rellenar las posiciones durante las horas de trabajo.

Figura 18. Ejemplos de preguntas como parte de una encuesta de post-usabilidad

Realimentación de Participantes 1. Usar esta bomba de infusión fue intuitivo:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ _____________________ 2. Tengo inquietudes acerca de usar esta

bomba inteligente de infusión en mi entorno de enfermería:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales: ____________________ _________________________ 3. Esta bomba inteligente de infusión facilitará

mi trabajo como enfermera:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ________________________ 4. Usar esta bomba inteligente de infusión

cambiará cómo pienso acerca de programar una boma:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales: ____________________

5. Usar esta bomba de infusión en mi unidad

ayudará a mejorar la seguridad del paciente:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________

_________________________ 6. Me pareció que el conjunto de tareas durante

el escenario fue difícil de completar:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales :____________________ ___________________________ 7. Estoy segura de haber completado todas las

tareas durante el escenario:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ______________________________ 8. El entrenamiento que recibí fuú suficiente

para permitirme completar todos los escenarios:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales: ___________________

99

Sección 8.5.11.3 Estrategias de reclutamiento

Para comenzar a reclutar, se recomienda que se comunique con: (1) los expertos clínicos que proporcionaron retroalimentación sobre sus escenarios clínicos, y (2) los líderes de las unidades donde se implementará la tecnología o el cambio de sistema. La participación de estos miembros del personal no sólo ayudará a asegurar que sus participantes sean representativos, sino que también facilitará el reclutamiento de los participantes, ya que pueden ayudar a facilitar el proceso de relleno de puestos y pueden fomentar la participación de su personal (por ejemplo, enviar un correo electrónico a todo el personal de la unidad, comunicar la importancia de las pruebas de usabilidad durante las reuniones del personal).

Para iniciar el contacto con participantes potenciales, el profesional en tecnología biomédica puede asistir a reuniones de personal, publicar carteles de reclutamiento y pedir a expertos y líderes clínicos que compartan información sobre la oportunidad de estudio con sus colegas. La estrategia de reclutamiento más eficaz tiende a presentar información sobre el estudio a posibles participantes en persona durante las reuniones regulares del personal. Si se utiliza este enfoque, prepárese para resumir y responder preguntas sobre la prueba de usabilidad durante la reunión. Un póster que resume la prueba de usabilidad, e incluye su información de contacto (Figura 19), debe ser presentado a la reunión para que pueda ser publicado en la unidad para aquellos que no están listos para decidir en el acto sobre su participación.

Alternativamente, si los participantes están siendo sustituidos en sus respectivas actividades diarias, durante el tiempo que dura la prueba, , usted podría pedirle al gerente clínico de la unidad que decida qué miembros del personal enviar para participar en pruebas de usabilidad. Sin embargo, si bien este enfoque facilita el reclutamiento desde la perspectiva del profesional de la tecnología biomédica, es menos probable que resulte en la contratación de participantes plenamente comprometidos y dispuestos a cooperar, y no suele ser un enfoque satisfactorio para pasar la mayoría de los comités la ética de la investigación.

Sección 8.5.11.4 Número de participantes en el reclutamiento

Para una prueba de usabilidad tradicional, se busca reclutar entre 5 y 15 usuarios representativos para cada área de especialización clínica. Cuantos más participantes participen en las pruebas, mayor será la probabilidad de que se identifiquen la mayoría de los problemas de usabilidad y diseño, y más comprensible será su comprensión de los problemas.

En el momento de la publicación, la FDA requiere que 15 usuarios finales representativos participen en pruebas de usabilidad para validar un nuevo diseño de dispositivo médico antes de recibir la aprobación de la FDA. Aunque quince usuarios por área clínica de especialización sería ideal para una prueba de usabilidad, puede no ser posible incluir a muchos participantes en las pruebas dirigidas por las instalaciones del hospital, dependiendo del número de personas disponibles para participar.

100

Al reclutar, es común que los participantes expresen su interés, y luego no puedan participar en la prueba real. Si es posible, planee reclutar un participante adicional para cubrir a un participante que no pueda asistir a la última hora. De esta manera, usted estará preparado para una cancelación de último minuto, e incluso si todo el mundo es capaz de asistir, el sujeto extra servirá para fortalecer la prueba de usabilidad añadiendo un participante más a la población de prueba.

Figura 19. Ejemplo de un póster que se utilizará para el reclutamiento y que resume la prueba de usabilidad

Sección 8.5.12. Realización de una Prueba de Usabilidad Piloto

Antes de las pruebas de usabilidad, se recomienda que se realice una sesión de prácticas o prueba piloto de usabilidad con su primer participante, o idealmente con un colega que esté dispuesto a pretender ser un participante. Una sesión piloto de prueba de usabilidad servirá para resaltar cualquier elemento preparatorio que falte o requiera modificación, antes de que empiecen las sesiones reales de prueba de usabilidad. Los datos recolectados de esta sesión piloto no deben incluirse como parte de sus datos reales de

Se necesitan enfermeras para una prueba de usabilidad de la bomba de infusión inteligente.

El hospital está en proceso de adquirir nuevas bombas de infusión inteligentes para varias áreas del hospital. El departamento de ingeniería clínica está buscando enfermeras que estén dispuestas a participar en una prueba de usabilidad que comparará los dos modelos de bombas de infusión inteligentes que está considerando el hospital.

Si está interesado, la participación incluirá una sesión de capacitación, la finalización de dos cuestionarios y una prueba de usabilidad para cada una de las dos bombas de infusión inteligentes. Una prueba de usabilidad es un método de factores humanos que ayuda a evaluar diferentes diseños de tecnología. Para esta prueba de usabilidad, se simularán una serie de tareas clínicas en un entorno de sala general basado en laboratorio, completo con equipos clínicos y escenarios, pero sin pacientes reales, medicamentos o atención real del paciente. Se espera que esta prueba de usabilidad tarde aproximadamente 1,5 horas en completarse. La información de esta prueba ayudará a informar la decisión del hospital sobre qué bomba de infusión inteligente comprar.

Elegibilidad; Usted es elegible para participar en este estudio si trabaja en el hospital y tiene al menos un año de experiencia general en enfermería.

Comuníquese con John Smith al 555-555-5555 si está interesado en participar o si desea obtener más información sobre este estudio.

101

prueba de usabilidad, y debe permitir suficiente tiempo entre la sesión piloto y el inicio de las pruebas de usabilidad para incorporar cualquier cambio.

Completar una sesión piloto de prueba de usabilidad le permite asegurar que el entorno, la introducción de participantes, el proceso de consentimiento, las encuestas, el entrenamiento y los escenarios de prueba de usabilidad estén preparados y que su presentación de cada parte y la transición de uno a otro fluyan suavemente. La ejecución de una sesión piloto de prueba de usabilidad le ofrece la oportunidad de practicar la grabación de la sesión, utilizando su herramienta de recopilación de datos en tiempo real y, para una prueba de alta fidelidad, para comunicarse con el facilitador de la sala de pruebas.

Sección 8.5.13. Lista de comprobación de la prueba de usabilidad antes de ejecutar la primera sesión

Como se describe en esta sección, hay una serie de elementos que deben prepararse antes de realizar una prueba de usabilidad para asegurar que su prueba se ejecute sin problemas y que obtenga el máximo provecho del tiempo invertido en la prueba. La siguiente lista de verificación (Figura 20) describe los elementos que deben estar listos antes de la prueba de usabilidad

Figura 20. Lista de verificación de resumen de los elementos necesarios antes de la prueba de usabilidad

Sección 8.6. Completar una prueba de usabilidad

La conclusión real de una prueba de usabilidad tiende a ser bastante sencilla, siempre y cuando todo el trabajo preparatorio se haya hecho exhaustivamente, antes de la prueba.

Información y cartel de reclutamiento Guión introductorio Formulario de consentimiento Encuesta de prueba de pre-usabilidad Contenido de entrenamiento Guiones de Usabilidad Herramientas de documentación de datos y portátil Espacio de prueba Tecnología o cambio de sistema que se está probando Suministros y equipo (por ejemplo, bomba de infusión, juegos de tubos, bolsas de IV,

cama de hospital, paciente simulado, monitor de paciente, ventilador, recipiente para utensilios cortantes, mesa de hospital, desinfectante para manos,

Equipo de grabación de video / audio y trípodes Encuesta posteroir de usabilidad

102

Sección 8.6.1. Visión general de la sesión de prueba de usabilidad

Cada sesión de prueba de usabilidad debe ser completada por un solo participante a la vez, y cada participante debe seguir los pasos descritos en la Figura 21 a continuación. Se debe asignar un número interno único de participante a cada participante para su inclusión en toda la información relacionada con la sesión del participante, incluyendo hojas de documentación de datos y grabaciones de video. Los participantes no necesitan saber o ser conscientes de sus números como participantes internos. Estos códigos internos simplemente tienen la intención de ayudarle a delinear entre varias sesiones de los participantes, manteniendo la confidencialidad.

A su llegada, el participante debe ser bien recibido, el facilitador le entrega el guión introductorio y pasa por el proceso de consentimiento informado. Una vez firmado el formulario de consentimiento, el participante debe completar la encuesta de pre-usabilidad, la sesión de entrenamiento, la sesión de usabilidad, la encuesta de post-usabilidad y una sesión informativa informal. Si se están probando múltiples tecnologías o cambios en el sistema, este proceso es repetido por cada participante.

Figura 21. Resumen del proceso de prueba de usabilidad

Sección 8.6.2. Recursos necesarios para ejecutar una sesión de prueba de usabilidad

Para aprovechar al máximo cada sesión, se recomienda que además del participante, al menos tres personas estén presentes para ayudar a ejecutar cada sesión de prueba de usabilidad. En la figura 22 se incluye una sugerencia de cómo dividir las responsabilidades durante la sesión de prueba de usabilidad. No es factible esperar que una sola persona facilite la sesión, documentar las observaciones en tiempo real y administrar las cámaras. Si sólo una persona está disponible para ejecutar el test de usabilidad, entonces lo mejor es establecer una o más cámaras de tal manera que capturen tanto detalle como sea posible sin necesidad de ser movido o ampliado y el facilitador debe documentar las observaciones en tanto detalle cuanto pueda durante la sesión.

103

Figura 22. Responsabilidades sugeridas durante la sesión de prueba de usabilidad

Dependiendo de la complejidad de los escenarios de prueba de usabilidad y el guion, puede ser necesario tener más de un actor presente para ayudar a facilitar los escenarios de prueba. Dependiendo del propósito y contexto de su prueba de usabilidad, también puede ser necesario tener más de una persona recolectando datos.

Si los recursos limitan la cantidad de personal disponible para ayudar a ejecutar una prueba de usabilidad, se debe prestar atención a facilitar la sesión y capturar la mayor cantidad de información posible en tiempo real en la herramienta de documentación de datos. Las cámaras de vídeo todavía se pueden configurar, pero es probable que tengan que permanecer estacionarias durante la prueba de usabilidad.

Sección 8.6.3. Recopilación de datos durante los escenarios de pruebas de usabilidad

Dependiendo del entorno en el que se realicen las pruebas de usabilidad, el participante y la persona responsable de la recolección de datos pueden estar en la misma habitación o en una habitación diferente entre sí, a medida que se completan los escenarios de usabilidad. Cuando el participante y el recolector de datos están en la misma habitación, el recolector de datos debe encontrar un equilibrio entre estar lo suficientemente cerca del participante para ver lo que está sucediendo y mantener una distancia suficiente para que el participante no sienta presión adicional como resultado del observador estar demasiado cerca. Consulte el Capítulo 4 y la Sección 4.5.1 para obtener más información sobre cómo realizar observaciones y el efecto Hawthorne, respectivamente. Cuando el participante y el recopilador de datos están en diferentes salas, como es común en un laboratorio de usabilidad formal, la proximidad del recolector de datos al participante es de mucha menor preocupación.

104

Una vez que el participante haya completado todos los escenarios y la encuesta de post-usabilidad, se puede realizar una sesión informativa informal con el participante para solicitar cualquier retroalimentación que vaya más allá del alcance de las encuestas. Este es un buen momento para hacer a los participantes preguntas específicas sobre su sesión. Por ejemplo, si usted los ve hacer algo sorprendente, o si cometieron un error y no está seguro de lo que sucedió. Al hacer preguntas al participante, asegúrese de hacerlo de una manera que no las haga sentir incómodas si realizaron una tarea incorrectamente. Trate de evitar decirles que cometieron un error y, en su lugar, haga preguntas abiertas sobre cómo se acercaron a la tarea para obtener una comprensión de los factores que contribuyeron al error. Además, asegúrese de que cualquier pregunta que usted haga al participante no llegue a sesgar la respuesta. Vea el Capítulo 5, para más información sobre entrevistas sin introducir sesgos no intencionales.

Sección 8.7. Qué hacer con los resultados de la prueba de usabilidad

Las pruebas de usabilidad generan un gran volumen de datos en varios formatos diferentes, incluyendo hojas de cálculo de documentación de datos, archivos de vídeo de sesión de usabilidad, encuestas de pre y post-usabilidad y notas de sesiones informativas informales. El número de participantes que toman parte en las pruebas amplifica el volumen de datos generados. Como resultado, es normal que el análisis de los datos de la prueba de usabilidad se sienta abrumador al principio.

Sección 8.7.1. Datos de rendimiento del usuario

Un buen punto de partida es considerar el propósito primordial de las pruebas de usabilidad, que es evaluar cómo los usuarios finales representativos interactúan con una tecnología o un cambio en un sistema. Por lo tanto, el análisis del desempeño del usuario debe ser el enfoque principal de cualquier prueba de usabilidad.

Sección 8.7.1.1 Análisis de errores de uso

Para analizar el rendimiento del usuario, las hojas de cálculo de la documentación de datos tienden a ser la fuente más útil de datos. Las hojas de cálculo de la documentación de datos deben ser compiladas entre los participantes y hacer una determinación de qué tareas fueron "aprobadas" y que fueron "fracasadas". Cuando los participantes tienen dificultades para completar un paso de la tarea correctamente, esto es una señal de que investigación adicional debe centrarse en esta área. Desde una perspectiva de factores humanos "fallos", o errores de uso en una prueba de usabilidad son como un "marca X", indicando dónde debe comenzar a profundizar para descubrir los factores que contribuyeron a que el error ocurriera, en primer lugar. A menudo, estos factores contribuyentes se pueden determinar basándose en sus observaciones, o de la sesión de información informal realizada después del escenario.

Es importante tener en cuenta que las instancias en las que una tarea falló o se produjo un error se describen en términos del sistema en lugar del usuario. Por ejemplo, si el usuario analizó con éxito un código de barras de fármaco varias veces antes de introducir manualmente la información de fármaco y dosis en la bomba de infusión, se describiría el

105

error como "la bomba no proporciona retroalimentación adecuada al usuario cuando se escanea el código de barras". La adopción de una perspectiva de los factores humanos significa abrazar la filosofía de que los seres humanos no tienen la intención de causar daño y ya están trabajando tan duro como pueden para manejar complejos entornos sanitarios. Como resultado, las estrategias de mitigación de errores deben centrarse en el sistema y no en el usuario para que tengan un efecto positivo. Al profundizar para descubrir los factores que contribuyeron a un error, la pregunta que usted debe hacer continuamente es "qué características del sistema están contribuyendo a este error?"

Una vez identificados los errores de uso, es necesario evaluar el impacto de cada error. Esta tarea requiere el aporte de clínicos o usuarios finales representativos que entiendan las implicaciones de los errores realizados durante las pruebas de usabilidad. Cada error debe ser clasificado usando una escala de clasificación predefinida para poder determinar los errores más graves entre sí. Puede utilizarse una escala de calificación y las definiciones de su elección para adaptar el análisis, pero se incluye un ejemplo en la Tabla 6. Cuando un error de uso podría resultar en múltiples resultados de gravedad variable, se debería escoger el peor escenario como una estimación conservadora para propósitos de calificación relativa. Si hay opiniones divergentes sobre la gravedad de un error entre los miembros del equipo, deben ser discutidos hasta que se alcance un consenso.

Tabla 6. Ejemplo de una escala de clasificación de gravedad para errores de uso descubiertos durante las pruebas de usabilidad

El siguiente paso es considerar cómo los errores de uso pueden ser mitigados por la organización de salud. Este ejercicio debe realizarse en colaboración con expertos clínicos y otros representantes de la organización, tales como especialistas en tecnología de la información, gestores de riesgos, especialistas en seguridad de medicamentos, etc. La identificación de estrategias de mitigación propuestas es un ejercicio extremadamente

106

importante, especialmente si las pruebas de usabilidad se hicieron en el contexto de adquisiciones. Lamentablemente, no hay una tecnología perfecta, por lo que es probable que la organización tendrá que aceptar un conjunto de problemas de diseño que tienen el potencial de conducir a ciertos errores de uso. Tener un sentido de las estrategias de mitigación probablemente para abordar el conjunto de cuestiones de diseño de antemano es extremadamente útil para los tomadores de decisiones que se beneficiarán de ser capaz de ver la imagen completa de las implicaciones al decidir una tecnología sobre otra.

Las estrategias de mitigación que eliminen la posibilidad de que se produzca un error forzando a los usuarios a actuar con seguridad serán las más efectivas. Sin embargo, es importante que estas estrategias sean apropiadas y los usuarios sientan que los apoyan y que se desarrollarán soluciones con el tiempo. Ejemplos de estos tipos de soluciones incluyen personalizaciones de productos que limitan ciertas características u opciones dentro del sistema, estandarizando procesos o sistemas y automatizando tareas. La capacitación no suele considerarse una estrategia eficaz para mitigar los errores, a menos que el error se deba a la falta de conocimientos técnicos sobre los principios fundamentales del sistema. Un marco para evaluar la eficacia de los diversos tipos de estrategias de mitigación se presenta en la Sección 3.5 La Jerarquía de la Efectividad.

Al analizar las tareas con las que los participantes tuvieron dificultades, es más importante identificar la presencia de un error de uso que determinar la frecuencia de ese error de uso. Esto es especialmente cierto cuando el error de uso podría provocar graves daños al paciente. Independientemente de si un solo participante cometió un error que podría conducir a un grave daño al paciente, el error aún vale la pena abordar porque incluso un incidente de daño del paciente es uno demasiado.

Sección 8.7.1.2 Análisis de tiempo para la finalización de tareas

Además de identificar los errores de uso, otra medida que puede ser útil para cuantificar el rendimiento del usuario es la cantidad de tiempo requerida para completar varios pasos de la tarea. Una vez más, las hojas de cálculo de documentación de datos son útiles porque los sellos de tiempo introducidos como participantes completan cada paso de un proceso pueden utilizarse como base para calcular cuánto tiempo tomaron las distintas tareas. De esta manera, las tecnologías o los cambios del sistema se pueden comparar basándose en el tiempo promedio requerido por los participantes para completar las tareas en cada caso.

Sección 8.7.1.3 Análisis del Conocimiento y la Experiencia

Las respuestas de las preguntas de la encuesta que apuntan a poner de relieve el conocimiento y la experiencia de los participantes relacionados con un cambio de tecnología o sistema pueden usarse para proporcionar contexto al interpretar los datos de rendimiento del usuario. Cuando los participantes son menos conocedores o experimentados con un cambio de tecnología o sistema como lo demuestran las respuestas de la encuesta, puede señalar la necesidad de programas de capacitación y educación para los usuarios finales.

107

Sección 8.7.2. Datos de preferencia del usuario

Además del rendimiento de los usuarios, las preferencias de los usuarios también pueden evaluarse sobre la base de las encuestas y de los datos informativos informales. Las respuestas de la encuesta relacionadas con las preferencias de los usuarios deben ser compiladas entre los participantes para que los resultados agregados puedan ser compartidos. Las estadísticas descriptivas se pueden utilizar para analizar los resultados de la encuesta. Como se describe en la Sección 5.1 Paradoja de Desempeño vs Preferencia, los datos de las preferencias de los usuarios son beneficiosos al proporcionar el contexto, pero no deben usarse aisladamente de los datos de rendimiento del usuario.

Sección 8.7.3. Comunicar los resultados a otros

Dado que el volumen de datos generados por una prueba de usabilidad tiende a ser grande, es importante para el profesional de la tecnología biomédica destilar y presentar hallazgos clave para que sean comprensibles para una variedad de audiencias.

Un informe resumido puede ser útil para comunicar los resultados de las pruebas de usabilidad de manera consistente a otros en toda la organización. Un informe de esta naturaleza debería ser de nivel bastante alto, con información detallada incluida en los apéndices, según se requiera. Incluyendo cualquier estadística descriptiva que muestre cosas como el número de problemas que tienen el potencial de resultar en resultados de pacientes severos o críticos para cada cambio de tecnología o sistema, pueden ser útiles para cuantificar sus hallazgos de usabilidad para una audiencia interesada en este tipo de comparación. También se recomienda altamente la incorporación de información sobre los procesos considerados, los métodos utilizados, los escenarios probados y los problemas identificados. Un informe es una excelente manera de compartir las estrategias de mitigación propuestas para utilizar los errores identificados mediante las pruebas. Dado que no hay una tecnología perfecta, es probable que la organización tenga que vivir con una variedad de problemas de diseño que tienen el potencial de conducir a ciertos errores de uso. Pensando en cómo se utilizarían esos errores de uso para las tecnologías que se están considerando puede ayudar a los tomadores de decisiones a conceptualizar qué tecnología está asociada con el menor riesgo dado los recursos disponibles dentro de la organización.

Además de escribir un reporte, la preparación de un video que muestre a múltiples participantes haciendo los mismos errores de uso puede causar una fuerte impresión al comunicar los resultados a otros. Si se prepara un video, asegúrese de que no hay información de identificación mostrada de los participantes (por ejemplo, desenfoque las caras, desdibujar cualquier característica distintiva). Un video de realce de error de uso es efectivo para mostrar cuál es el problema, cómo se manifiesta en múltiples participantes y escenarios, e indica que el problema es realmente un problema de sistemas, en oposición a un problema con una persona específica, ya que varias personas experimentaron el mismo problema.

En resumen, adaptar la forma en que los resultados de usabilidad se comunican y se presentan a los diferentes interesados pueden contribuir en gran medida a optimizar los esfuerzos invertidos en una prueba de usabilidad. Cuando se comunican con eficacia, todos,

108

desde la administración de la organización sanitaria hasta las líneas de frente, pueden beneficiarse de las pruebas de usabilidad.

Sección 8.8. Pruebas de Usabilidad Comparativa

Las pruebas de usabilidad son un método eficaz para comparar múltiples productos del mismo tipo de tecnología (por ejemplo, durante la adquisición de tecnología médica). El proceso para realizar pruebas comparativas de usabilidad es similar al proceso de prueba de usabilidad descrito en este capítulo, con algunas excepciones y consideraciones que se describirán en esta sección.

Sección 8.8.1. Introducción

Cuando presente al participante en la sesión, hágales saber el número de productos que van a evaluar. Al introducir cada uno de los productos, asegúrese de que todos los productos se refieren a objetivamente, incluso si hay un producto que personalmente piensa que es superior a los demás. Del mismo modo, al probar múltiples soluciones, o cambios en el sistema, no proporcionan información al participante acerca de quién desarrolló varias soluciones, o qué solución o cambio cree que será mejor.

Sección 8.8.2. Diseño del escenario

En una prueba comparativa de usabilidad, cada participante evaluará todos los productos en una sola sesión. Para acomodar esto, la longitud de cada escenario necesitará reflejar el tiempo total disponible para la sesión de prueba (es decir, no más de 2,5 horas). Además, dado que los participantes repetirán cada escenario en cada producto, se necesitarán crear escenarios equivalentes pero diferentes para cada producto para minimizar los efectos de aprendizaje. Un escenario diferente pero equivalente es un escenario que requiere las mismas tareas y tiene las mismas características (por ejemplo, interrupciones, errores plantados), pero tiene una historia o contexto diferente. Por ejemplo, un escenario para la evaluación de las bombas de infusión es que la presión arterial de un paciente está cayendo y por lo que el participante necesita titular el medicamento que controla la presión arterial. Un escenario diferente, pero equivalente, podría ser que un paciente se queja de un aumento del dolor y por lo que el participante debe titular la medicación del dolor.

Sección 8.8.3. Contrapeso

En una prueba comparativa de usabilidad, el orden en el que cada participante comprueba cada producto también debe compensarse para minimizar los efectos del aprendizaje. Es decir, una proporción igual de sus participantes deben usar cada dispositivo primero, segundo, tercero, etc.

Sección 8.8.4. Formación

En una prueba comparativa de usabilidad, el entrenamiento para cada producto debe ser entregado inmediatamente antes de probar ese producto. Proporcionar capacitación sobre todos los productos a la vez (antes de comenzar la prueba) sesgará los resultados hacia

109

el entrenamiento que se dio en último lugar. Además, si el entrenamiento en todos los productos se hace con varios días de anticipación, es menos probable que se retenga que si el entrenamiento en un dispositivo se da por adelantado, que es el enfoque común durante el proceso de implementación.

Sección 8.8.5. Cuestionario posterior a la prueba

En una prueba comparativa de usabilidad, los cuestionarios posteriores a la prueba se deben administrar inmediatamente después de que se pruebe cada producto. Después de que todas las pruebas estén completas, se debe administrar un cuestionario final para obtener un resumen de los pensamientos del participante en todos los productos.

110

Factores Humanos y Métodos de análisis Informados de Riesgo e Incidente

Dos Ingenieros de Factores Humanos que trabajan con un farmacéutico de oncología para comprender modos de fallo asociados con órdenes de medicamentos.

111

Capítulo 9. Factores Humanos, Análisis Informado de Modo de Fallo y Efectos

Sección 9.1. Preparando el escenario

Análisis de Modo de Fallo y Efectos (FMEA) es un método de ingeniería para evaluar proactivamente vulnerabilidades en un sistema antes de que los riesgos causen daño. Fue utilizado por primera vez a finales de 1940 por las Fuerzas Armadas de los Estados Unidos para analizar varios sistemas de control de vuelo (Amzen, 1996), ya que errores del piloto condujeron a accidentes y muertes. Desde entonces, FMEA ha sido adaptado y utilizado en varias industrias, incluyendo militar, aeroespacial, automotriz, plásticos, servicio de alimentos, y más recientemente, en la asistencia sanitaria. FMEA ha sido promovido por varias organizaciones nacionales de seguridad y calidad en Canadá y los Estados Unidos, entre ellas: la Administración de Salud de Veteranos [37], el Instituto de Prácticas Seguras de Medicamentos [38], el Instituto de Prácticas Seguras de Medicamentos de Canadá [39], y El Instituto de Mejora de la Salud [40].

La realización de un FMEA es un medio para que los hospitales cumplan los estándares de acreditación en los Estados Unidos y Canadá, incluyendo la norma LD.5.2 de la Comisión Conjunta de Seguridad del Paciente en el capítulo de Liderazgo del Manual de Acreditación Hospitalaria [41] y las Prácticas Operativas Requeridas de Acreditación en Canadá, que determina la realización cada año de al menos una evaluación proactiva de riesgo, de un proceso de alto riesgo [42].

Existen muchas versiones del método FMEA en múltiples industrias, incluyendo el Análisis del Modo de Fallo y efectos de la Atención médica (HFMEA). Este capítulo presentará un método informado FMEA de factores humanos (HFFMEA) adaptado para analizar de forma proactiva los sistemas de atención médica y asegurar que las consideraciones de factores humanos se incluyan en el proceso.

Sección 9.2. ¿Qué es HFFMEA?

HFFMEA es un método de análisis de factores humanos utilizado para identificar los riesgos dentro de un sistema de forma proactiva. Es llevado a cabo por un equipo multidisciplinario, y puede ser utilizado para evaluar los flujos de trabajo, o procesos tecnológicos. HFFMEA le ayuda a considerar:

¿Qué puede salir mal (modo de fallo)

¿Qué sucede si sale mal (efectos)

Si fallara, cuan severo, probable y detectable sería (Priorizando en qué enfocarse)

¿Por qué podría salir mal (causas)?

¿Qué estrategias podrían evitar que se vaya mal (estrategias de mitigación)?

112

El HFFMEA tiene como objetivo mejorar el método FMEA más tradicional incorporando una serie de métodos de factores humanos durante el análisis para:

Habilitar la identificación de los modos de falla desde una perspectiva de factores

humanos

Tenga en cuenta nuestras fortalezas y limitaciones humanas naturales al calificar

y priorizar asuntos

Identificar causas desde una perspectiva de factores humanos

Identificar estrategias informadas de mitigación de factores humanos y establecer

expectativas sobre cuánto riesgo es probable que se mitigue dadas las soluciones

propuestas.

Además de incorporar métodos de factores humanos a lo largo del análisis, HFFMEA también apoya al profesional de la tecnología biomédica para asegurar que los problemas críticos surjan con mayor facilidad y que los recursos se enfoquen en los problemas y soluciones de mayor riesgo / mayor recompensa, de manera que el esfuerzo general requerido pueda ser optimizado.

Sección 9.3. ¿Por qué utilizar HFFMEA?

HFFMEA proporciona un medio de entender los riesgos potenciales que existen dentro de un sistema de una manera proactiva, y desde una perspectiva de factores humanos. La capacidad de identificar y abordar los riesgos antes de que conduzcan a un problema de seguridad del paciente o del personal es una oportunidad de oro para reducir el daño real.

HFFMEA puede unir a personal de toda la organización que tiene diferentes orígenes profesionales y que trabajan en diferentes entornos, reuniéndolos para identificar y resolver problemas como un grupo. Este tipo de iniciativa puede fortalecer la cultura organizacional y ayudar a crear un sentimiento de unidad entre el personal. La participación de un grupo de personal servirá para generar un análisis más sólido y estrategias de mitigación que cualquier grupo clínico o unidad podría lograr por sí mismos, y ayudará a lograr apropiación cuando llegue el momento de implementar estrategias de mitigación identificados a través del análisis.

Desde la perspectiva del profesional de la tecnología biomédica, completar un HFFMEA será útil para:

Examinar y gestionar de forma proactiva los riesgos para la seguridad de los

pacientes

Comparar los riesgos asociados con múltiples tecnologías o procesos comparables

al decidir qué implementar, por ejemplo, para la adquisición

Identificar las debilidades del sistema que pueden estar relacionadas con un

incidente, pero no directamente

113

Cumplir con los requisitos de acreditación para completar al menos una

evaluación proactiva de riesgos anualmente.

Sección 9.4. ¿Cuándo usar HFFMEA?

HFFMEA puede utilizarse para respaldar varias responsabilidades clave de un profesional de la tecnología biomédica, incluida la gestión del riesgo, la adquisición, la gestión de incidentes y el cumplimiento de los requisitos de acreditación.

Para gestionar el riesgo de manera proactiva, debe seleccionarse y analizarse un proceso potencialmente problemático o de alto riesgo, con cualquier estrategia mitigadora identificada a través del análisis que se está implementando para evitar que el daño del paciente y del personal se llegue a manifestar. El establecimiento de estrategias de mitigación antes de que se experimente cualquier daño es el mejor escenario para la seguridad de los pacientes y el manejo de incidentes.

Para la adquisición, los procesos realizados por el personal al interactuar con las tecnologías que se están considerando pueden analizarse y compararse utilizando HFFMEA. La aplicación de esta herramienta de análisis de factores humanos permite comparar el conjunto de modos de fallo y las estrategias mitigadoras propuestas a través de las posibles tecnologías para tomar una decisión informada sobre el nivel de riesgo resultante que la organización sanitaria está dispuesta a asumir.

Después de un incidente, o de un análisis de causa raíz (RCA) (Capítulo 10), HFFMEA puede aplicarse para descubrir deficiencias más generales del sistema que van más allá de los modos de falla que condujeron directamente al incidente. Ampliar el espectro del análisis usando HFFMEA puede destacar otros riesgos paralelos y circundantes que no saldrían a la luz usando HFRCA solo.

Muchos organismos de acreditación requieren que al menos una evaluación de riesgo proactiva sea completada por una organización de salud anualmente. HFFMEA se puede utilizar para analizar un proceso considerado arriesgado por la organización, o como resultado de un incidente de seguridad, para cumplir este requisito.

Sección 9.5. Completando un HFFMEA

El proceso de HFFMEA consta de siete pasos, esbozados en la Figura 23. Cada paso será descrito y descrito en esta sección.

114

Figura 23. Los siete pasos y oportunidades para incorporar factores humanos como parte de HFFMEA

Sección 9.5.1. Seleccione un proceso

El primer y más crítico paso de un HFFMEA es seleccionar un proceso para analizar. En el contexto de este tipo de análisis, un proceso puede considerarse una serie de tareas orientadas a lograr un objetivo con un principio y un final definidos. Un proceso puede estar centrado alrededor de una tecnología, o puede definir una serie de tareas de flujo de trabajo necesarias para lograr una meta.

Al elegir un proceso, debe ser suficientemente alto riesgo y error propenso a justificar el esfuerzo involucrado en la realización de un análisis. La comparación del riesgo residual asociado con las diferentes opciones de tecnología para la adquisición y el análisis de los riesgos generales relacionados con un incidente crítico justifican generalmente un HFFMEA. Para identificar modos de fracaso de manera prospectiva e independiente de un incidente o de un ejercicio de adquisición, considere la posibilidad de revisar las bases de datos de incidentes de su organización sanitaria u otras organizaciones que recopilan datos de incidentes como el Instituto de Prácticas Seguras de Medicamentos, FDA, ECRI Institute, National Health Service (NHS) (Reino Unido), Australia Fundación para la Seguridad del Paciente y revisar documentos de orientación de las organizaciones de defensa de la seguridad tecnológica de la salud como el Instituto ECRI, la Asociación para el Avance de Instrumentación Médica, INAHTA y organismos de acreditación como The Joint Commission. Si se trata de decidir entre dos procesos candidatos para el análisis de considerar los siguientes factores, que influirá en el éxito probable de una HFFMEA.

¿El área clínica (s) asociada con el proceso está comprometida a participar? Las

áreas clínicas que han tenido incidentes relacionados con el proceso que se

investiga suelen estar dispuestas a comprometerse a apoyar el análisis e

implementar estrategias de mitigación.

115

¿Existe un campeón evidente en la (s) unidad (es) que participará (n) como parte

del equipo de HFFMEA y actuará como enlace con el (los) área (s) clínica? Tener

un campeón dentro de la unidad clínica es clave para acceder al área clínica,

observar el sistema de trabajo y recoger artefactos para apoyar un HFFMEA.

¿Se está preparando el área clínica para experimentar un cambio relacionado con

el proceso que se está evaluando? Si la unidad ya se está preparando para un

cambio relacionado (por ejemplo, comprando e implementando un nuevo

dispositivo asociado con el proceso propuesto) es más probable que apoyen un

HFFMEA.

¿Es el proceso omnipresente en toda la organización (es decir, afecta a muchas

áreas clínicas)? Si los resultados del HFFMEA beneficiarán muchas áreas clínicas,

el esfuerzo puede tener un mayor beneficio.

¿Está el proceso alineado con las prioridades organizacionales más amplias? La

elección de un tema relacionado con algo que la organización está midiendo

activamente facilitará el apoyo de la alta dirección.

Sección 9.5.1.1 Definición de los puntos inicial y final del proceso

Para apoyar un HFFMEA exitoso, el alcance del proceso incluido para el análisis debe estar claramente definido. Para ello, deben establecerse los puntos de inicio y finalización del proceso, ya que estos son los límites que definirán el alcance del análisis. Un alcance de proceso bien definido y manejable es esencial para evitar que los recursos y el alcance requeridos escalen fuera de control. Cuando se define un alcance de proceso para el análisis, inclínese siempre hacia un proceso muy estrecho, en lugar de un proceso que puede ser muy amplio, ya que prácticamente no existe un proceso demasiado estrecho para la aplicación de HFFMEA.

Sección 9.5.1.2 Definición de Criterios de Inclusión y Exclusión

Para ayudar a definir el alcance del proceso para un HFFMEA, considere el proceso propuesto en varios niveles y defina explícitamente lo que se incluirá y excluirá. Las categorías de información a incluir o excluir dependen del proceso bajo consideración, pero algunas comunes incluyen: Población de pacientes, área del cuidado, tecnología. La Tabla 7 proporciona un ejemplo de algunas de las variables que podrían ser consideradas para inclusión / exclusión al definir el alcance para el proceso de administración de quimioterapia usando una bomba de infusión ambulatoria.

Sección 9.5.2. Ensamble un equipo

Una vez que se han definido el proceso, los puntos de inicio y fin y los criterios de inclusión y exclusión, se debe montar un equipo para realizar el análisis. Los equipos deben ser multidisciplinarios, representando una gama de conocimientos, experiencias, antecedentes y perspectivas.

116

Tabla 7. Ejemplo de variables que pueden ser explícitamente incluidas o excluidas de un HFFMEA al definir el alcance para el proceso de administración de quimioterapia usando una bomba de infusión ambulatoria.

Las personas que usted elija para participar en un equipo de HFFMEA dependerá del proceso y el alcance que se analiza. En la medida de lo posible, los miembros del equipo deben estar bien informados sobre el alcance del proceso definido, y que piensen críticamente, y proporcionen aportaciones, retroalimentación, orientación y compromiso en varias etapas del ejercicio HFFMEA.

Proceso Definido: Administración de Quimioterapia con una bomba ambulatoria de infusión

Incluido Excluido

Población de Pacientes √

Adulto √

Pediátrico √

Pruebas clínicas

Dispositivos de Entrega

Bomba electrónica ambulatoria de infusión √

Bomba elastomérica de infusión √

Bomba de infusión de gran volumen √

IV push √

Entorno

Paciente hospitalizado √

Paciente de Consulta Externa √

Comunidad √

Casa √

Pasos de la Tarea

Ordenar la quimioterapia √

Seleccionar la bomba correcta √

Mezclar la quimioterapia para la bomba √

Verificación de cinco reglas antes de conectar √

Conectar el paciente a la bomba √

Programar la bomba √

Iniciar la bomba √

Infundir con la bomba √

Desconectar la bomba √

Personas

Médico de oncología √

Farmacia √

Enfermería √

Pacientes √

Familia y público √

117

Sección 9.5.2.1 Funciones de miembros del equipo

Los miembros individuales del equipo necesitan cumplir una serie de funciones diferentes para asegurar un proyecto exitoso. Cada equipo de HFFMEA debe incluir miembros individuales que puedan servir como expertos en materia o proceso, revisores de procesos y asesores senior. Además, algunos de estos mismos miembros del equipo tendrán que asumir los roles de líder de equipo o facilitador, secretario y experto en factores humanos.

Expertos en la Materia o en Procesos

Los expertos en la materia o en procesos son individuos que tienen un conocimiento detallado de las tecnologías, procesos y entornos que se están estudiando. Estos miembros del equipo serán fundamentales para mapear el proceso que se está analizando, identificando los riesgos potenciales, evaluando y calificando los riesgos, y proporcionando información al proponer e identificar el impacto de las estrategias de mitigación.

Revisor de procesos

Los revisores de procesos son individuos que están menos familiarizados con el proceso que se analiza, pero que tienen experiencia y conocimiento en un campo relacionado. Los revisores de procesos son importantes para proporcionar una revisión crítica de prácticas y estándares que son aceptados por la comunidad. Es más probable que los miembros del equipo que cumplan esta función identifiquen vulnerabilidades que no sean detectadas por los expertos en procesos.

Asesores Senior

Los asesores senior tienden a ser un ejecutivo del hospital, o un miembro del personal de alto nivel, que puede proporcionar una amplia perspectiva organizativa al equipo. Estas personas ayudan a facilitar el acceso a los recursos, tales como personas y apoyo financiero, que son necesarios para llevar a cabo una HFFMEA. Los asesores senior también desempeñan un papel clave en el logro de la adhesión de las áreas de la organización de salud donde los cambios se implementarán sobre la base de las estrategias de mitigación identificadas en el análisis y para facilitar cualquier cambio en las políticas.

Líder de equipo o Facilitador

El líder del equipo o facilitador es un miembro del equipo que es responsable de mantener el debate en movimiento y en el objetivo durante las reuniones. El líder del equipo debe fomentar la participación de los miembros del equipo que pueden ser más reacios a expresar sus ideas. El líder del equipo debe tener confianza en sí mismo, ser bueno en la gestión de personas, dinámicas de grupo y ser capaz de facilitar la construcción de consenso en el grupo. El líder del equipo no tiene que ser la misma persona que el líder del proyecto o coordinador.

Secretario

El secretario es responsable de capturar la discusión y las decisiones tomadas en cada reunión y distribuir las actas de la reunión a todo el equipo.

118

Experto en factores humanos

Idealmente, uno de los miembros del equipo de HFFMEA tendrá entrenamiento de factores humanos. La perspectiva de los factores humanos para un HFFMEA es importante porque las fortalezas y limitaciones humanas se consideran al identificar y calificar los modos de falla, y al identificar causas y recomendaciones. La aplicación de una visión de factores humanos, tal como se describe para este método, proporcionará información adicional para cada una de estas etapas de HFFMEA. Si no es posible incluir un experto en factores humanos, un profesional en tecnología de la salud puede aplicar el nuevo objetivo de los factores humanos (proporcionado por este libro y los recursos adicionales mencionados en este libro) al proceso para cumplir este rol y desarrollar la experiencia de factores humanos. Otra opción más rentable a considerar es traer a un estudiante graduado de factores humanos y su asesor para ayudar a proporcionar esta perspectiva.

Sección 9.5.2.2 Tamaño del equipo

Los equipos de HFFMEA generalmente varían en tamaño de tres a ocho personas, pero el número exacto dependerá del alcance del proceso y de cuántas partes interesadas se ven afectadas por el proceso analizado. Cuando se incluyen pocos miembros del equipo en un HFFMEA, el análisis será menos robusto, con la posibilidad de ser incompleto, si no se incluyen perspectivas relevantes. Cuando se incluyen demasiados miembros del equipo, puede ser cada vez más difícil programar reuniones, coordinar y compilar el trabajo de los miembros del equipo y llegar a un consenso.

Un equilibrio eficaz puede ser alcanzado iniciando con un equipo más grande, pero luego dividiendo ese equipo en un equipo de trabajo y un equipo asesor. El equipo de trabajo debe estar compuesto por dos o tres personas que son responsables de llevar a cabo el análisis detallado y de informar al equipo más grande. El equipo de trabajo debe reunirse varias veces y dedicar su tiempo a dirigir el trabajo práctico, incluyendo la creación de diagramas, la formulación del análisis y la producción de informes. Esta parte del equipo se puede considerar los "hacedores". El equipo asesor, que compone el balance de todo el equipo de HFFMEA, es responsable de revisar el análisis del equipo de trabajo y proporcionar la orientación y los recursos necesarios en varias reuniones clave. Esta parte del equipo puede ser considerada como "habilitadores". Las reuniones clave se llevan a cabo a lo largo de un HFFMEA para asegurar que las perspectivas, la experiencia y las ideas de todas las partes interesadas se incluyan en el análisis. En esta sección, cada una de las reuniones clave se describen utilizando cuadros de texto para resaltar su propósito y

119

estructura. El primer encuentro se lleva a cabo una vez que el equipo es seleccionado y se propone un proceso.

Sección 9.5.3. Documentar el proceso

Una vez que el equipo se ha reunido y se ha llegado a un consenso sobre el alcance del proceso (es decir, los puntos de inicio y fin, criterios de inclusión y exclusión), el proceso debe documentarse. Documentar el proceso significa crear una representación gráfica de los pasos y sub-pasos necesarios para completar el alcance del proceso elegido. Se puede crear cualquier estilo de representación gráfica, pero para los propósitos de este manual se recomienda un diagrama de flujo del proceso. Para aprender a crear un diagrama de flujo de proceso, consulte el Capítulo 6 Análisis de tareas.

La creación de un diagrama de flujo de proceso es un proceso iterativo, en lugar de lineal. Para crear un diagrama de flujo de proceso para un HFFMEA, primero los miembros del equipo de trabajo deben crear un diagrama basado en una comprensión inicial de lo que sucede como parte del proceso. A continuación, los miembros del equipo asesor que también se consideren revisores de procesos deben revisar este diagrama. Luego, el equipo de trabajo debe ir al campo para realizar observaciones (Capítulo 4) y entrevistas (Capítulo 5) para validar el diagrama de flujo del proceso. Es muy importante que el proceso real, en contraposición al proceso ideal, sea documentado, ya que esto formará la base del HFFMEA. Este enfoque iterativo de revisar el diagrama, ir al campo para aclarar y validar y actualizar el diagrama debe repetirse hasta que no haya discrepancias entre el diagrama y lo que sucede en el campo.

Para un HFFMEA exitoso, es esencial que las observaciones y las entrevistas se lleven a cabo por una serie de razones. En primer lugar, es casi seguro que entrar en el campo dará nueva información que podría afectar el alcance del proceso. A medida que se realizan las observaciones y las entrevistas, es posible que aprendan a relacionar equipos, suministros, nuevos grupos de usuarios o diferentes áreas del hospital, por ejemplo, que tengan un impacto en el proceso que se está estudiando. En estos casos, el alcance del proceso puede tener que expandirse para un análisis exitoso. En contraste, a través de las observaciones puede resultar evidente que el alcance del proceso original elegido es demasiado grande y complejo para gestionar con el tiempo y los recursos disponibles. En este caso puede ser

Reunión de equipo # 1:

Asistentes: equipos de trabajo y asesoramiento

Propósito: conocerse; revisar el alcance del proceso

Duración estimada: 1-2 horas

Una vez identificados los equipos de trabajo y asesoramiento, la primera reunión debe centrarse en revisar y obtener consenso para el proceso elegido, los puntos de inicio y fin y los criterios de inclusión y exclusión.

120

necesario reducir el alcance del proceso. De cualquier manera, cualquier cambio en el alcance del proceso debe estar claramente definido en términos de puntos de inicio / final y criterios de inclusión / exclusión, y también debe ser apoyado tanto por el equipo de trabajo como por el equipo asesor.

Además de reevaluar el alcance del proceso, las observaciones y las entrevistas también son útiles para agregar detalles, llenar las lagunas de comprensión y evitar situaciones en las que se están haciendo suposiciones sobre un proceso. Los procesos son casi siempre más detallados y complejos de lo originalmente supuesto, por lo que es importante entrar en el campo para apoyar la creación de un diagrama preciso. Aunque es importante un diagrama preciso, es posible incluir demasiados detalles. Saber cuánto detalle documentar (es decir, si incluir o excluir ciertas subtareas) puede ser un verdadero desafío al crear un diagrama de flujo de proceso para soportar un HFFMEA. Apoyar la creación de un diagrama que tenga un nivel de detalle adecuado, para cada tarea y subtarea, hágase la pregunta "¿esta tarea o subtarea cae dentro del ámbito de este HFFMEA". Un alcance claramente definido, con puntos de inicio y de fin, así como criterios de inclusión y exclusión, puede contribuir en gran medida a apoyar este enfoque.

Para hacer que el diagrama de flujo del proceso sea tan útil como sea posible para los propósitos de un HFFMEA, se recomienda que cada paso y sub-paso sean numerados para facilitar al grupo discutir los pasos individuales a lo largo del proceso de análisis. Cuando hay variaciones diferentes en los mismos pasos del proceso, cada variación debe ser documentada en el mapa del proceso y etiquetada para que quede claro que una de las variaciones tendrá lugar. El etiquetado de las variaciones con las letras, además de los números, puede ayudar a ilustrar esto (por ejemplo, las subtareas 1.2.a, 1.2.b, 1.2.c representan las tres formas diferentes en que se alcanza la subtarea 1.2). Utilizar los carriles, que permiten que un proceso sea asignado para representar diversas áreas clínicas o gente en un proceso, también se recomienda altamente para la claridad mejorada.

Una vez que se haya creado el borrador final del diagrama de flujo del proceso utilizando el enfoque iterativo de revisar, entrar en el campo y actualizar el diagrama, se debe compartir con el personal de primera línea que esté familiarizado con el proceso. Debido a que leer un diagrama de flujo del proceso puede ser bastante tedioso, se recomienda que se establezcan una o más reuniones para que pueda recorrer a los revisores a través del diagrama paso a paso. Durante este ejercicio, las notas deben hacerse directamente en el diagrama sobre cualquier área donde se requieran cambios. Si surge información nueva que cambia significativamente el diagrama de flujo del proceso, se recomienda realizar más observaciones para validar cualquier cambio.

Después de que se hayan hecho más actualizaciones, el diagrama de flujo del proceso debe ser distribuido entre el equipo asesor por lo menos una semana antes de la Reunión # 2 del Equipo. Se recomienda proporcionar una versión electrónica y una versión en papel del documento para facilitar la revisión y edición por parte de los miembros del equipo.

121

Sección 9.5.4. Identificar los modos de falla y efectos

Una vez que el diagrama de flujo del proceso ha sido finalizado y aprobado por los equipos de trabajo y asesoramiento, el siguiente paso es identificar los posibles modos de fallo (FM) y los efectos para el alcance del proceso definido. El Centro Nacional para la Seguridad del Paciente de los Asuntos de los Veteranos define un modo de fracaso como "diferentes maneras en que un proceso o un subproceso puede no proporcionar el resultado esperado" [43]. En otras palabras, un modo de fallo es una descripción de cómo fallan las cosas. Es importante resaltar que las cosas fallan es diferente de por qué las cosas fallan. Por ejemplo, al hacer el pan tostado, un modo de fallo sería la tostada se quema. Por qué las cosas fallan describe la causa de un modo de fallo. En el ejemplo del pan tostado, un posible por qué podría ser que el ajuste de la tostadora era demasiado alto. Comprender por qué las cosas fallan es importante, pero será considerado más adelante en el proceso de HFFMEA. La razón de esta distinción es porque la identificación de una lista exhaustiva de causas es extremadamente lenta. El método HFFMEA enfoca el tiempo dedicado a identificar las causas sólo en los modos de fallo más serios e importantes tal como se determina mediante el proceso de calificación del modo de fallo.

Para facilitar la identificación de los modos de fallo y para soportar el resto del método HFFMEA, un miembro del equipo de trabajo debe convertir el diagrama de flujo del proceso final en un formato de hoja de cálculo. Para ello, cada tarea numerada y subtarea del diagrama de flujo de proceso, junto con las descripciones de tareas correspondientes, se deben introducir en filas en la hoja de cálculo. Consulte la Tabla 8 para ver un ejemplo de una plantilla de hoja de cálculo HFFMEA con pasos de descripción de flujo de proceso introducidos en filas.

Reunión de equipo # 2:

Asistentes: equipos de trabajo y asesoramiento

Propósito: revisar el diagrama de flujo del proceso

Duración estimada: medio día

El borrador final del diagrama de flujo del proceso debe ser discutido en detalle, con un miembro del equipo de trabajo guiando el grupo a través del diagrama paso a paso. Cada miembro del equipo debe tener una copia impresa del diagrama de flujo de proceso que se puede utilizar para las notas y para seguir la guía durante la sesión. Sobre la base de la discusión durante la reunión, es probable que se produzcan más cambios en el diagrama de flujo del proceso, incluido el cambio de alcance.

Deje tiempo suficiente para esta reunión, especialmente para un proceso de largo alcance y considere la posibilidad de traer refrescos para los miembros del equipo.

122

Tabla 8. Ejemplo de una hoja de cálculo HFFMEA con información de descripción de flujo de proceso introducida

Una vez que se ha inicializado la hoja de cálculo HFFMEA, el grupo de trabajo debe reunirse y revisar sistemáticamente cada paso y sub paso de la tarea para identificar cualquier posible modo de falla. Para cada paso y sub paso, la pregunta cómo podría este paso o paso secundario va mal debe ser contestada, con la respuesta que va en la columna de la descripción del modo del fallo.

Si hay más de un posible modo de fallo para un paso de tarea determinado o un sub paso, todos deben estar incluidos. Cuantos más modos de fallo se puedan identificar y enumerar, mejor, porque cuando se desarrolla una lista completa, se incrementa el potencial para reducir el riesgo de los modos de fallo identificados. Al identificar los modos de fallo, tenga en cuenta que es común que el mismo modo de fallo esté asociado con diferentes pasos y sub pasos de la tarea. Para ayudar a generar una lista completa de modos de fallo, las siguientes preguntas pueden plantearse

¿Cómo se podría realizar este paso o sub etapa incorrectamente?

¿Cómo se podría realizar este paso o sub etapa de manera incompleta?

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Verificar paciente correcto

2.0 Verificar droga correcta

3.0 Verificar dosis correcta

4.0 Verificar vía correcta

5.0 Verificcr tiempo correcto

6.0 Conectar línea IV al paciente

7.0 Encender la bomba

8.0 Entrar a la libreria de drogas

9.0 Seleccionar la droga

… ….

… ….

… ….

123

Si este paso o sub paso se intenta correctamente, ¿qué podría impedir que se

complete correctamente?

¿Qué sucedería si se omitiera una tarea que es parte de este paso o sub-paso?

La inclusión de un experto en factores humanos o la incorporación de lo que se conoce acerca de los factores humanos al identificar los modos de fallo resultará en una lista más completa de los modos de fallo y un análisis más robusto. Considere las limitaciones humanas inherentes como la memoria, fatiga y sesgos cognitivos (Capítulo 3).

Tabla 9. Ejemplo de una hoja de cálculo HFFMEA con la descripción del flujo de proceso y los modos de fallo introducidos

Es importante reiterar que HFFMEA es un método de análisis de riesgo prospectivo, lo que significa que independientemente de si un modo de fracaso ha ocurrido realmente, o lo poco probable que pueda parecer, todavía debe ser incluido en la hoja de cálculo para su posterior consideración.

Para identificar los posibles efectos de cada modo de fallo, el equipo de trabajo debe pensar en lo que podría suceder si se produjo el modo de fallo. Cuando son posibles varios efectos diferentes, en lugar de enumerar todas las posibilidades, incluya los efectos más serios posibles para ser lo más conservador posible sobre el riesgo.

Al identificar los efectos, piense en el objetivo general del proceso que se está analizando, en lugar de sólo el efecto más inmediato. Por ejemplo, a partir de la Tabla 10, si

Tarea # Modo de Falla (MF) Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Verificar paciente correcto

1 Paciente correcto no verificado

2.0 Verificar droga correcta

2 Droga correcta no verificada

3.0 Verificar dosis correcta

3 Dosis correcta no verificada

4.0 Verificar vía correcta 4 Vía correcta no verificada

5.0 Verificcr tiempo correcto

5 Tiempo correcto no verificado

6.0 Conectar línea IV al paciente

6 Línea no conectada al paciente

7.0 Encender la bomba 7 Bomba no encendida

8.0 Entrar a la libreria de drogas

8 No entró a librería de drogas

9.0 Seleccionar la droga 9 Droga no seleccionada

… …. 10 Droga errada seleccionada

124

el proceso que se está analizando es la administración de quimioterapia con una bomba de infusión ambulatoria y un modo de fallo es # 6, el tubo no está unido al paciente, un efecto inmediato es que el paciente no se conecta a su infusión, pero en el contexto de la meta general del proceso, los efectos son fuga de medicación, y el paciente no recibe su quimioterapia. Evite tomar el efecto más allá de esto, (por ejemplo, el paciente muere), porque esto se extiende más allá del objetivo del proceso como se define (por ejemplo, administrar quimioterapia al paciente usando una bomba de infusión ambulatoria). El efecto del paciente que no recibe su quimioterapia (por ejemplo, el paciente muere) será capturado como parte del proceso de calificación de riesgo para la gravedad del efecto.

Tabla 10. Ejemplo de una hoja de cálculo HFFMEA con descripción del flujo de proceso, modos de fallo y efectos ingresados

Una vez que el equipo de trabajo haya identificado tantos posibles modos de fallo y los efectos resultantes como sea posible para cada paso y sub etapa del proceso, la hoja de cálculo debe ser distribuida al equipo asesor para su revisión.

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Verificar paciente correcto

1 Paciente correcto no verificado

Paciente errado

2.0 Verificar droga correcta

2 Droga correcta no verificada

Droga errada

3.0 Verificar dosis correcta

3 Dosis correcta no verificada

Dosis errada

4.0 Verificar vía correcta

4 Vía correcta no verificada

Vía errada

5.0 Verificcr tiempo correcto

5 Tiempo correcto no verificado

Tiempo errado

6.0 Conectar línea IV al paciente

6 Línea no conectada al paciente

Fuga de medicamento

Paciente no recibe medicamento

7.0 Encender la bomba

7 Bomba no encendida

Paciente no recibe medicamento

8.0 Entrar a la libreria de drogas

8 No entró a librería de drogas

Enfermera no es alertada sobre posible dosis errada

9.0 Seleccionar la droga

9 Droga no seleccionada

La alarma de la bomba se active

… …. 10 Droga errada seleccionada

El paciengte recibe a droga errada

125

Sección 9.5.5. Califique los Efectos del Modo de Falla y determine los Modos Clave de Falla

Una larga lista de modos de fallo y efectos resultantes se habrán generado después de la Reunión # 3 del Equipo. Con recursos ilimitados, uno trataría de mitigar cada modo de falla identificado, pero como en realidad la mayoría de las organizaciones de salud no tienen la capacidad para hacer esto, es importante centrarse en corregir los modos de fallo que llevan el mayor riesgo. Para identificar qué modos de fallo son los problemas de mayor prioridad y por lo tanto requieren la mayor atención, cada modo de fallo y efecto se calificarán usando matrices de puntuación de riesgo y serán evaluados para determinar si es un modo de fallo clave (KFM). Una vez que se han identificado los KFM, el equipo puede centrarse en determinar las causas y crear estrategias de mitigación dirigidas a estos

Reunión de equipo # 3:

Asistentes: equipos de trabajo y asesoramiento

Propósito: revisar y ampliar los posibles modos de fallo y efectos

Duración estimada: 1 día

Los modos de fallo y los efectos de cada etapa y sub etapa del proceso deben ser revisados, discutidos y ampliados durante esta reunión. El facilitador debe guiar al grupo a través de cada paso y sub-paso y obtener cualquier retroalimentación o modos de fallo adicionales para cada paso. Cada miembro del equipo debe tener una copia impresa de la hoja de cálculo y el diagrama de flujo de proceso que se puede utilizar para las notas, y para seguimiento durante la sesión. Si es posible, proyecte una copia de trabajo de la hoja de cálculo para que todo el equipo pueda verla y haga que el escribano escriba cualquier tipo de fallo nuevo o modificado y efectos en tiempo real para que el equipo pueda asegurar que la discusión se está capturando con precisión.

Además de los modos de fallo y efectos, es probable que también se presenten causas. Para mantener esta reunión en marcha cualquier causa debe ser registrada en un archivo o papel separado, para uso futuro y el facilitador debe dirigir el grupo de nuevo hacia la identificación y revisión de los modos de fallo y efectos.

Es normal que se produzcan nuevas modificaciones en el diagrama de flujo del proceso como resultado de esta reunión. Haga que el secretario u otro miembro del equipo dedicado capture los cambios necesarios en una copia impresa del diagrama de flujo del proceso para que puedan incorporarse después de la reunión.

Esta será la reunión más larga del HFFMEA, y un día entero debe ser programado, especialmente para un alcance de proceso más grande. Si no es posible programar una reunión de este largo, el plan para tener varias reuniones más cortas en su lugar. Organizar refrescos para el equipo y asegúrese de programar varias pausas cortas durante todo el día.

126

problemas de alta prioridad para que los recursos disponibles puedan ser utilizados de la manera más eficiente posible.

Matrices de puntuación de riesgo son rúbricas que apoyan la asignación de puntos de riesgo a cada efecto de modo de fallo. En el marco HFFMEA dos matrices se requieren para apoyar la identificación de los modos de fallo clave, una matriz de puntuación de gravedad y una matriz de puntuación de probabilidad.

Las calificaciones y las definiciones utilizadas para evaluar la gravedad y la probabilidad de cada modo de fallo deben adaptarse al proceso que se analiza, pero valores sugeridos para las matrices de puntuación de gravedad y de probabilidad se incluyen en la Tabla 11 como ejemplos.

Es importante que las definiciones y la escala elegidas sean apropiadas y significativas para el alcance del proceso que se está evaluando. Por ejemplo, si varios de los modos de fallo que se están considerando son probables que ocurren diariamente, la definición de "Frecuente" en la Tabla 12 debe ajustarse para tener esto en cuenta.

El proceso de creación de matrices de puntuación de riesgo puede ser más eficiente si el equipo de trabajo desarrolla matrices propuestas y las hace circular y recibe comentarios por correo electrónico, en lugar de reunirse en persona.

Una vez que las matrices de puntuación de riesgo hayan sido desarrolladas y aprobadas por los equipos de trabajo y asesoramiento, el grupo de trabajo deberá reunirse varias veces para asignar puntuaciones de gravedad y probabilidad a cada modo de fallo y efecto en la hoja de cálculo HFFMEA. Al calificar la gravedad, considere el efecto del modo de fallo, y al caificr la probabilidad, considere el modo de fallo en sí mismo. (Tabla 13).

Si es posible, incluya un experto en factores humanos en este ejercicio de calificación porque tener esta perspectiva permitirá considerar las fortalezas y limitaciones inherentes de las personas, posiblemente afectando las puntuaciones asignadas a diferentes problemas. Piense en las limitaciones humanas inherentes como la memoria, la fatiga y los sesgos cognitivos (Capítulo 3). Un fallo común cuando se califican modos y efectos de fallo es asumir que las personas deberían estar vigilantes cuando se trata de un problema potencial, o que deberían recordar hacer algo, pero una visión de factores humanos ayudará a recordar al grupo que en realidad, esto no es posible.

Una vez que el equipo de trabajo haya evaluado cada modo y efecto de fallo, la hoja de cálculo HFFMEA debe ser distribuida al equipo asesor para su revisión y retroalimentación. Se debe programar una reunión tanto para el equipo de trabajo como para el equipo asesor para revisar y discutir en persona las puntuaciones de gravedad y probabilidad asignadas, para que cualquier desacuerdo pueda ser discutido hasta que se alcance un consenso.

127

Tabla 11. Ejemplo de matriz de puntuación de gravedad

Tabla 12. Ejemplo de matriz de puntuación de probabilidad

Probabilidad

Calificación Descripción Definición

1 Remoto Poco probable que ocurra (una vez cada 5-30 años)

2 Poco común Es posible que ocurra (puede ocurrir una vez en 2-5 años)

3 Ocasional Probable que ocurra (puede ocurrir más de una vez en 1-2 años)

4 Frecuente Probable que ocurra (puede ocurrir varias veces durante un año)

128

Tabla 13. Puntuaciones de gravedad y probabilidad para cada modo de fallo y efecto

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Verificar paciente correcto

1 Paciente correcto no verificado

Paciente errado

3 3

2.0 Verificar droga correcta

2 Droga correcta no verificada

Droga errada 3 3

3.0 Verificar dosis correcta

3 Dosis correcta no verificada

Dosis errada 3 3

4.0 Verificar vía correcta

4 Vía correcta no verificada

Vía errada 3 3

5.0 Verificcr tiempo correcto

5 Tiempo correcto no verificado

Tiempo errado

2 4

6.0 Conectar línea IV al paciente

6 Línea no conectada al paciente

Fuga de medicamento

1 2

Paciente no recibe medicamento

3 2

7.0 Encender la bomba

7 Bomba no encendida

Paciente no recibe medicamento

3 1

8.0 Entrar a la libreria de drogas

8 No entró a librería de drogas

Enfermera no es alertada sobre posible dosis errada

3 4

9.0 Seleccionar la droga

9 Droga no seleccionada

La alarma de la bomba se active

1 2

… …. 10 Droga errada seleccionada

El paciengte recibe a droga errada

3 2

… ….

… ….

129

Sección 9.5.5.1 Aplicación de las tres pruebas

Una vez que la gravedad y la probabilidad de cada modo de fallo y efecto se ha calificado utilizando las matrices de gravedad y probabilidad, se aplican una serie de tres pruebas para determinar los modos clave de fallo. Las tres pruebas son la prueba de gravedad, la prueba de puntuación de peligro y la prueba de debilidad de punto único. Las pruebas deben aplicarse de acuerdo con el árbol de decisión representado en la Figura 24.

Prueba 1: Prueba de gravedad

Se elige un umbral de severidad examinando los modos de fallo asociados con cada valor de puntuación (o rango de valores de puntuación, dependiendo del rango de las matrices de puntuación) y determinando qué tipos de fallos asociadas con cada puntuación / rango de puntuación son importantes para mitigar. Tenga en cuenta que si un modo de fallo tiene múltiples efectos, cada efecto tendrá su propia calificación de gravedad. Cualquier modo de fallo y efecto que tenga una gravedad superior o igual al umbral elegido se convertirá automáticamente en un modo clave de fallo que se analiza más. En la Tabla 11, el

Reunión de equipo # 4:

Asistentes: equipos de trabajo y asesoramiento

Objetivo: Determinar las matrices de puntuación de riesgo y llegar a un consenso sobre la gravedad y la probabilidad de los modos de falla y efectos

Duración estimada: 3 a 4 horas

Ahora que los modos y efectos de fallo han sido revisados, el equipo de trabajo debe presentar la matriz de puntuación de riesgo propuesta para su revisión y discusión. Cualquier modificación de la matriz de puntuación de riesgo debe hacerse basándose en el consenso del grupo sobre la escala de calificación y definiciones.

Las calificaciones de gravedad y probabilidad se asignarán a cada par de modo de fallo y efecto durante esta reunión. El facilitador debe guiar al grupo por cada modo de fallo y la puntuación propuesta determinada por el grupo de trabajo. Los equipos de asesoramiento y de trabajo deben votar para determinar si la puntuación asignada es aceptable. Cualquier desacuerdo debe ser resuelto mediante discusión para llegar a un consenso. Cada miembro del equipo debe tener una copia impresa de la hoja de cálculo HFFMEA con la puntuación propuesta, así como una copia de las matrices de puntuación de riesgo para la gravedad y la probabilidad. Si es posible, proyecte una copia de trabajo de la hoja de cálculo de HFFMEA para que todo el equipo pueda verla y haga que el secretario actualice la puntuación en tiempo real.

Dependiendo del alcance del proceso y del número de modos de fallo y efectos a calificar, se programarán entre tres y cuatro horas. Traiga refrescos para los miembros del equipo si es posible.

130

umbral de gravedad es 3 y, por lo tanto, todos los modos de fallo asociados con una clasificación de gravedad de 3 o más se clasifican como KFM.

Tabla 14. Aplicación de la prueba de gravedad

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

¿MFC?

1.0 Verificar paciente correcto

1 Paciente correcto no verificado

Paciente errado

3 3 Y Y

2.0 Verificar droga correcta

2 Droga correcta no verificada

Droga errada 3 3 Y Y

3.0 Verificar dosis correcta

3 Dosis correcta no verificada

Dosis errada 3 3 Y Y

4.0 Verificar vía correcta

4 Vía correcta no verificada

Vía errada 3 3 Y Y

5.0 Verificcr tiempo correcto

5 Tiempo correcto no verificado

Tiempo errado

2 4 N

6.0 Conectar línea IV al paciente

6 Línea no conectada al paciente

Fuga de medicamento

1 2 N

Paciente no recibe medicamento

3 2 Y Y

7.0 Encender la bomba

7 Bomba no encendida

Paciente no recibe medicamento

3 1 Y Y

8.0 Entrar a la libreria de drogas

8 No entró a librería de drogas

Enfermera no es alertada sobre posible dosis errada

3 4 Y Y

9.0 Seleccionar la droga

9 Droga no seleccionada

La alarma de la bomba se active

1 2 N

… …. 10 Droga errada seleccionada

El paciengte recibe a droga errada

3 2 Y Y

… ….

… ….

131

Prueba 2: Prueba de puntuación de peligro

Para determinar la puntuación de riesgo de cada modo de fallo y efecto, los puntos de gravedad y probabilidad se multiplican juntos. Tenga en cuenta que si un modo de fallo tiene múltiples efectos, cada efecto tendrá su propia puntuación de peligro. Una vez que se han determinado las puntuaciones de peligro, se elige de nuevo un umbral basado en el tipo de modos de fallo asociados con cada puntaje de peligro. Cualquier modo de fallo y efecto que tenga una puntuación de riesgo mayor o igual que el umbral de riesgo elegido se considerará más adelante (Tabla 15) aunque puede no convertirse en un KFM.

Tabla 15. Aplicación de la prueba de puntaje de peligro

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Verificar paciente correcto

1 Paciente correcto no verificado

Paciente errado

3 3 Y Y Y

2.0 Verificar droga correcta

2 Droga correcta no verificada

Droga errada 3 3 Y Y Y

3.0 Verificar dosis correcta

3 Dosis correcta no verificada

Dosis errada 3 3 Y Y Y

4.0 Verificar vía correcta

4 Vía correcta no verificada

Vía errada 3 3 Y Y Y

5.0 Verificcr tiempo correcto

5 Tiempo correcto no verificado

Tiempo errado

2 4 N Y ?

6.0 Conectar línea IV al paciente

6 Línea no conectada al paciente

Fuga de medicamento

1 2 N N

Paciente no recibe medicamento

3 2 Y N Y

7.0 Encender la bomba 7 Bomba no encendida

Paciente no recibe medicamento

3 1 Y N Y

8.0 Entrar a la libreria de drogas

8 No entró a librería de drogas

Enfermera no es alertada sobre posible dosis errada

3 4 Y Y Y

9.0 Seleccionar la droga

9 Droga no seleccionada

La alarma de la bomba se active

1 2 N N

… …. 10 Droga errada seleccionada

El paciengte recibe a droga errada

3 2 Y N Y

132

Para aquellos modos de fallo con puntuaciones superiores o iguales al umbral de riesgo elegido, se tendrán que hacer dos consideraciones para determinar si se trata de un KFM.

Consideración 1: ¿Se controla el modo de fallo de manera efectiva?

Un modo de fallo efectivamente controlado tiene una intervención que es inherente al sistema que elimina o reduce sustancialmente la probabilidad de un fallo del sistema o un evento adverso. Por ejemplo, para el modo de fallo asociado con el paso 8 del proceso de la Tabla 16, "No ingresar a la biblioteca de fármacos", algunas organizaciones pueden controlar eficazmente este modo de fallo mediante el uso de un sistema de códigos de barras que identifica al proveedor de cuidado cada vez que la bomba está programada. Si un control de calidad en la unidad acompaña al personal cada vez que se libera la librería de fármacos, este modo de fallo probablemente ocurrirá con poca frecuencia y sólo con una justificación apropiada. En este caso, la respuesta a la consideración 1 es sí.

Consideración 2: ¿Es detectable el modo de fallo?

Se considera que un modo de fallo detectable es un peligro obvio que es probable que se detecte y mitigue, y como resultado, no requiere una medida de control eficaz.

Para determinar si un modo de fallo es detectable, deben considerarse las siguientes preguntas. Si alguna de las siguientes afirmaciones es verdadera, el modo de fallo NO es detectable y debe analizarse más:

1. No hay manera posible de detectar el error

2. El fallo puede ser detectado solamente a través de la inspección y no es factible o

fácilmente hecho

3. El error se puede detectar con la inspección manual pero no hay ningún proceso

en curso, luego la detección se deja al azar

4. Existe un proceso de doble verificación o detección pero el proceso se basa en la

vigilancia y / o se aplica sólo a una muestra

Aquellos modos de fallo que tienen una puntuación de riesgo por encima del umbral elegido y que no son ni controlados de manera efectiva ni detectables, se consideran KFM, y se analizarán adicionalmente.

Si un modo de fallo tiene una puntuación de riesgo por encima del umbral elegido y es controlado de forma efectiva, detectable o ambos, se documentará pero no se analizará (Tabla 16).

133

Tabla 16. Identificación de modos de fallo controlados y detectables

Prueba 3: Prueba de debilidad de punto único

La última prueba a ser aplicada es la prueba de debilidad de punto único. Esta prueba se aplica a los modos de fallo con una puntuación de peligro que es menor que el umbral elegido. Una debilidad de punto único es un fallo que por sí sola resultaría en un fallo del sistema o un evento adverso. Si un modo de fallo se identifica como una debilidad de punto

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Verificar paciente correcto

1 Paciente correcto no verificado

Paciente errado

3 3 Y Y Y

2.0 Verificar droga correcta

2 Droga correcta no verificada

Droga errada 3 3 Y Y Y

3.0 Verificar dosis correcta

3 Dosis correcta no verificada

Dosis errada 3 3 Y Y Y

4.0 Verificar vía correcta 4 Vía correcta no verificada

Vía errada 3 3 Y Y Y

5.0 Verificcr tiempo correcto

5 Tiempo correcto no verificado

Tiempo errado

2 4 N Y Y N N

6.0 Conectar línea IV al paciente

6 Línea no conectada al paciente

Fuga de medicamento

1 2 N N

Paciente no recibe medicamento

3 2 Y N Y

7.0 Encender la bomba 7 Bomba no encendida

Paciente no recibe medicamento

3 1 Y N Y

8.0 Entrar a la libreria de drogas

8 No entró a librería de drogas

Enfermera no es alertada sobre posible dosis errada

3 4 Y Y Y

9.0 Seleccionar la droga 9 Droga no seleccionada

La alarma de la bomba se active

1 2 N N

… …. 10 Droga errada seleccionada

El paciengte recibe a droga errada

3 2 Y N Y

… ….

… ….

134

único, las mismas dos consideraciones tendrán que hacerse como para la prueba de puntuación de riesgo para determinar si se trata de un KFM.

Consideración 1: ¿Se controla el modo de fallo de manera efectiva?

Consideración 2: ¿Es detectable el modo de fallo?

Si la debilidad de punto único no es controlada o detectable de manera efectiva, se considerará un KFM y se analizará más a fondo.

Si la debilidad de punto único es controlada de forma efectiva, detectable o ambas cosas, no se considerará un modo de fallo clave. Se documentará, pero no se analizará (Tabla 17)

Tabla 17. Prueba de debilidad de punto único

Tarea # Modo de Falla (MF) Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Verificar paciente correcto

1 Paciente correcto no verificado

Paciente errado 3 3 Y Y Y

2.0 Verificar droga correcta

2 Droga correcta no verificada

Droga errada 3 3 Y Y Y

3.0 Verificar dosis correcta

3 Dosis correcta no verificada

Dosis errada 3 3 Y Y Y

4.0 Verificar vía correcta

4 Vía correcta no verificada

Vía errada 3 3 Y Y Y

5.0 Verificcr tiempo correcto

5 Tiempo correcto no verificado

Tiempo errado 2 4 N Y Y N N

6.0 Conectar línea IV al paciente

6 Línea no conectada al paciente

Fuga de medicamento

1 2 N N N Y Y

Paciente no recibe medicamento

3 2 Y N Y

7.0 Encender la bomba

7 Bomba no encendida

Paciente no recibe medicamento

3 1 Y N Y

8.0 Entrar a la libreria de drogas

8 No entró a librería de drogas

Enfermera no es alertada sobre posible dosis errada

3 4 Y Y Y

9.0 Seleccionar la droga

9 Droga no seleccionada

La alarma de la bomba se active

1 2 N N N N

… …. 10 Droga errada seleccionada

El paciengte recibe a droga errada

3 2 Y N Y

135

Solamente aquellos modos de fallo y efectos considerados como KFM a través de este proceso de calificación y clasificación serán considerados en el futuro para el HFFMEA.

Figura 24. Árbol de decisión utilizado para determinar si un modo de falla es un modo clave de falla

Sección 9.5.6. Identificar Causas

Sólo los modos de fallo que se determinen como KFM serán considerados para el resto del análisis. Una vez que se han identificado los KFMs, el equipo de trabajo debe reunirse para revisar los KFMs y comenzar a identificar las causas, o las razones detrás de cada KFM. En esta etapa del análisis, es probable que los equipos de trabajo y asesoramiento hayan identificado una serie de causas, las cuales deberían ser capturadas en las notas de la reunión del equipo. Cualquier causa debe ser revisada y, si es pertinente, incorporada en el análisis en la hoja de cálculo de HFFMEA junto a cualquier KFM y efectos pertinentes.

El equipo de trabajo debe entonces revisar sistemáticamente cada KFM y efecto y pensar sobre las posibles causas de ese modo de fallo. Cuando se piensa en las posibles causas, o en los porqués detrás de cada modo clave de fallo, es importante ir más allá del primero, y más próximo por qué, dado que es la causa raíz más que las causas proximales las que son de interés para una HFFMEA. Es importante ir más allá de ese primero, y más próximo , ya que si la causa raíz puede ser identificada y tratada, es mucho más probable que se aborde el problema real, en lugar de simplemente agregar un parche a la superficie

136

del problema. La identificación y tratamiento de las causas profundas aumentará la probabilidad de que se reduzca el riesgo asociado con la KFM.

Algunos peligros comunes a evitar al identificar las causas son (1) sólo pensar en las causas centradas en el ser humano, y (2) centrarse en el cumplimiento de los protocolos y procedimientos establecidos.

Piense más allá de las causas centradas en el hombre

Todos somos humanos y todos cometemos errores. En consecuencia, como el equipo de trabajo piensa acerca de las posibles causas de cada KFM, asegúrese de ir más allá de simplemente decir que el usuario podría realizar la acción incorrecta, y considerar las razones subyacentes por qué una acción incorrecta podría realizarse. Si no se piensa más allá de las causas centradas en el ser humano, no se producirá un cambio significativo en el sistema tal como se pretende para el HFFMEA. Para apoyar el pensamiento más allá de las causas centradas en el ser humano, continuamos preguntando por qué, después de que una causa humana ha sido identificada. Por ejemplo, para el proceso administración de quimioterapia con una bomba de infusión ambulatoria, una causa del modo de fallo ess que el tubo no está unido al paciente puede ser que la enfermera se distraiga. En lugar de detenerse aquí, el equipo de trabajo debe preguntar por qué la enfermera puede distraerse. Tal vez en este caso, cada enfermera es responsable de varios pacientes y todos tienden a interrumpir con preguntas sobre su medicación. Ir más allá de la causa centrada en el ser humano (es decir, la distracción en este caso) a una causa a nivel de sistema (es decir, interrupciones frecuentes por parte de los pacientes y alta carga de trabajo de la enfermera) significa que se pueden desarrollar estrategias mitigadoras para conducir a cambios significativos en el sistema. Tal vez si a los pacientes se les dio una oportunidad dedicada a hablar con un médico o farmacéutico antes de recibir sus medicamentos, tendrían menos preguntas para las enfermeras cuando sus infusiones se están configurando.

Piense más allá del cumplimiento de los protocolos y procedimientos establecidos

Problemas relacionados con el cumplimiento del personal serán las causas de ciertos KFM en casi todas las HFFMEA, sin embargo, es importante señalar que el incumplimiento de los protocolos y procedimientos establecidos rara vez es resultado de rebelión o mala voluntad por parte del personal. En su lugar, casi siempre hay problemas de sistema más amplios en juego tales como niveles de personal, programación, falta de familiaridad con los protocolos, protocolos imposibles de implementar, prácticas de trabajo diferentes y otras presiones de trabajo que permiten estas desviaciones. Al identificar las causas, asegúrese de que el equipo de trabajo piense más allá de cualquier problema de cumplimiento, para identificar las presiones subyacentes del sistema y conseguir que el cambio significativo del sistema pueda lograrse a través de estrategias atenuantes adaptadas y apropiadas.

Cuando se identifican las causas, si el equipo de trabajo es incapaz de pensar más allá de las causas centradas en el ser humano o el cumplimiento, es altamente recomendable otros métodos de factores humanos, tales como observaciones (capítulo 4), entrevistas

137

(capítulo 5), heurística (capítulo 7) o las pruebas de usabilidad (Capítulo 8) para obtener las causas raiz de por qué podría ocurrir un modo de fallo.

Una vez que el equipo de trabajo ha identificado las causas de cada KFM, la hoja de cálculo HFFMEA debe ser distribuida al equipo asesor para su revisión y cualquier retroalimentación. Se debe programar una reunión con los equipos de trabajo y de asesoramiento para revisar y discutir las causas raíz identificadas para cada KFM.

Sección 9.5.7. Desarrollar e implementar estrategias de mitigación

El paso final de un HFFMEA es desarrollar e implementar estrategias de mitigación que aborden las causas raíz de los principales modos de falla con el fin de reducir la gravedad, o la probabilidad, o aumentar la detectabilidad de un modo de falla. Desarrollar estrategias que se centran en cambiar el sistema, en lugar de estrategias que se centran en el cambio de la persona, es de suma importancia. Si las estrategias de mitigación apuntan a cambiar el comportamiento de una persona, o cómo interactúan con el sistema, puede haber una mejora temporal, pero con el tiempo, las presiones de trabajo y las limitaciones humanas inherentes conducirán a las personas hacia sus comportamientos de trabajo anteriores para que puedan cumplir con el trabajo demandas. Por el contrario, cuando las estrategias de mitigación se centran en el sistema, se pueden hacer mejoras radicales, en lugar de tratar de hacer cambios persona por persona. La implementación de una estrategia de mitigación a nivel de sistema significa que independientemente de la persona, o su conocimiento de las políticas, o su conciencia o vigilancia en un día determinado, el sistema está configurado para guiar a la gente a trabajar correctamente y con seguridad.

Reunión de equipo # 5:

Asistentes: equipos de trabajo y asesoramiento

Finalidad: finalizar causas raíz para cada modo de fallo de clave

Duración estimada: 2 a 3 horas

Las causas raíz de cada modo de falla clave serán revisadas, discutidas y finalizadas durante esta reunión. El facilitador debe guiar al grupo por las causas de cada modo clave de falla. Los equipos de asesoramiento y trabajo deben discutir y refinar las causas y cualquier desacuerdo se resuelve mediante discusión para llegar a un consenso.

Cada miembro del equipo debe tener una copia impresa de la hoja de cálculo HFFMEA. Si es posible, proyecte una copia de trabajo de la hoja de cálculo HFFMEA para que todo el equipo pueda verla, y haga que el escribano actualice las causas en tiempo real.

Dependiendo del alcance del proceso y el número de modos clave de falla para revisar, se programarán entre dos y tres horas. Traiga refrescos para los miembros del equipo si es posible.

138

Para apoyar el desarrollo de estrategias mitigadoras enfocadas en el sistema, en lugar de centradas en la persona, así como comparar la efectividad potencial relativa de diferentes estrategias, se recomienda que se use la Jerarquía de Eficacia (Sección 3.5). La Jerarquía de Eficacia debe ser distribuida a los miembros de los equipos de trabajo y asesoramiento y se debe programar una reunión para que ambos grupos trabajen juntos para comenzar a desarrollar estrategias de mitigación para abordar las causas raíz de la KFM.

Además de la eficacia de una estrategia de mitigación, es importante considerar la viabilidad de su implementación, dados los recursos disponibles. Una vez que los equipos de trabajo y asesoramiento hayan identificado una serie de posibles estrategias de mitigación que probablemente sean eficaces, el siguiente paso es considerar los recursos necesarios para una implementación adecuada. Los equipos de trabajo y de asesoramiento deberán completar un ejercicio de priorización que balancee la eficacia probable, los recursos necesarios y los recursos disponibles / viabilidad para cada estrategia de mitigación. No hay un proceso prescrito para priorizar las estrategias de implementación; sin embargo, un buen principio rector para elegir estrategias de mitigación es que es más efectivo implementar menos estrategias de mitigación, intensivas en recursos, que aborden temas de mayor riesgo que implementar muchas estrategias de mitigación de bajos recursos que abordan problemas de menor riesgo.

Reunión de equipo # 6:

Asistentes: equipos de trabajo y asesoramiento

Propósito: desarrollar estrategias de mitigación para abordar las causas raíz para cada modo clave de falla

Duración estimada: 2 a 3 horas

Las ideas sobre cómo mitigar las causas raíz de cada modo clave de fallo serán compartidas y discutidas en esta reunión. El facilitador debe alentar una variedad de ideas y asegurar que los miembros del equipo consideren la Jerarquía de Eficacia al proponer y discutir estrategias. Se requerirá un facilitador fuerte para mantener la discusión inclusiva y avanzar, mientras que recuerda a los miembros del equipo que piensen en la efectividad de la solución propuesta usando la Jerarquía de Efectividad.

Cada miembro del equipo debe tener una copia impresa de la hoja de cálculo HFFMEA. Si es posible, proyecte una copia de trabajo de la hoja de cálculo HFFMEA para que todo el equipo pueda verla, y que el secretario actualice las ideas para mitigar las estrategias en tiempo real.

Dependiendo del número de modos clave de fallo, deben programarse entre dos y tres horas de ejercicio. Traiga refrigerios para los miembros del equipo si es posible.

139

Para apoyar este ejercicio de priorización, se debe distribuir una copia de la hoja de cálculo HFFMEA con posibles estrategias de mitigación a los equipos de trabajo y asesoramiento para su revisión. Debería programarse una reunión para discutir y decidir cuál de las estrategias propuestas se impulsará para su implementación.

Sección 9.6. Qué hacer con un HFFMEA completado

Como parte de la Reunión de Equipos # 7, una vez que se han dado prioridad a las estrategias de mitigación y se ha tomado una decisión sobre las soluciones que se implementarán, se debe desarrollar un plan para apoyar la implementación exitosa de cada estrategia. El plan para cada estrategia debe describir (1) los individuos responsables de implementar la estrategia, (2) las medidas de resultado que se utilizarán para evaluar el éxito, (3) los plazos previstos, y (4) un plan para evaluar proactivamente los nuevos modos de fallo que probablemente estén asociados con los cambios del sistema realizados a través de la implementación de la estrategia de mitigación.

Reunión de equipo # 7:

Asistentes: equipos de trabajo y asesoramiento

Propósito: priorizar estrategias de mitigación, crear planes de implementación, concluir HFFMEA

Duración estimada: 2 a 4 horas

Las estrategias de mitigación presentadas en la Reunión de Equipo # 6 serán revisadas y priorizadas en base a la probable efectividad, los recursos requeridos y los recursos disponibles / factibilidad en cada caso. Es importante contar con asesores de alto nivel presentes en esta reunión, ya que tendrán el amplio conocimiento y autoridad organizacional para decidir qué estrategias mitigantes deberían ser implementadas.

Una vez que el grupo ha determinado qué estrategias de mitigación seguir adelante, el equipo debe desarrollar un plan de implementación (Sección 9.6, Qué hacer con un HFFMEA completado).

El secretario debe capturar toda discusión y cualquier punto de decisión en tiempo real, idealmente, con todas las notas proyectadas para que todos los miembros del equipo puedan verlas.

Dependiendo del número de estrategias de mitigación que se están considerando, y cuántas son probables avanzar para la implementación, entre dos y cuatro horas deben programarse. Traiga refrigerios para los miembros del equipo si es posible.

Aunque el trabajo de implementación continuará, esta es la última reunión oficial del equipo HFFMEA.

140

Cada estrategia de mitigación acordada debe entonces ser implementada en la organización sanitaria usando el plan desarrollado durante la Reunión # 7 del Equipo. Aunque no suele haber más reuniones programadas para el equipo de HFFMEA más allá de la Reunión de Equipo # 7, los responsables de implementar las estrategias de mitigación probablemente encontrarán útil mantener contacto con varios miembros del equipo para apoyo y orientación durante todo el proceso de implementación.

Se recomienda que el equipo de trabajo prepare un documento de resumen que describa el proceso HFFMEA, los miembros del equipo, las decisiones clave, las lecciones aprendidas y el progreso en la implementación de estrategias de mitigación hasta la fecha. Este documento debe ser distribuido al equipo asesor para su revisión y aprobación antes de compartir más ampliamente con la organización sanitaria y otros. Tener dicho documento puede proporcionar una gran cantidad de información para futuras HFFMEAs y actividades de acreditación, y es un medio para capturar cómo las estrategias de mitigación llegaron a ser implementadas.

Sección 9.7. Limitaciones de HFFMEA

Antes de conducir un HFFMEA es importante considerar algunas de las críticas y limitaciones de este método.

Sección 9.7.1. Los Recursos Requeridos

Como todos los enfoques de FMEA, los recursos necesarios para llevar a cabo una HFFMEA pueden ser sustanciales. Un equipo formado por varios profesionales está obligado a reunirse regularmente y realizar una serie de pasos para completar un análisis. Para abordar este desafío, el método HFFMEA tiene como objetivo reducir en cierta medida los recursos requeridos en comparación con los métodos FMEA más tradicionales. Esto se consigue moviendo el ejercicio de calificación del modo de fallo más temprano en el análisis, de modo que la mayor parte del tiempo invertido por el grupo se gasta examinando aquellos modos de fallo considerados como de riesgo más alto. Además, para ayudar a controlar los recursos requeridos, se recomienda encarecidamente que se elija un alcance de proceso bien definido antes de emprender una HFFMEA.

Sección 9.7.2. Imposible identificar cada modo de falla

No importa cuánto tiempo y esfuerzo se gasta identificando modos de fallo, es imposible identificar cada modo de fallo que podría ocurrir. Los sistemas de asistencia sanitaria son extremadamente complejos en comparación con muchas otras industrias en las que se utiliza FMEA debido a la variabilidad introducida por los pacientes y las condiciones cambiantes del paciente, así como el conocimiento, la experiencia y los modelos mentales del personal. Aunque cada modo de fallo posible no se descubrirá usando esta técnica, se puede confiar en HFFMEA para resaltar muchos modos de fallo con el potencial de consecuencias graves que no son fácilmente evidentes antes de aplicar el método. Si los recursos lo permiten, la aplicación de otros métodos de factores humanos como la evaluación heurística (capítulo 7) y la prueba de usabilidad (capítulo 8) durante el proceso HFFMEA pueden aumentar las posibilidades de identificar tantos modos de fallo como sea posible.

141

Sección 9.7.3. El puntaje de riesgo es subjetivo y solo permite un ranking relativo

Asignar puntuaciones de peligro a cada modo de fallo es subjetivo, y como tal, diferentes equipos de análisis podrían asignar diferentes puntuaciones de peligro al mismo modo de fallo. Así, la calificación del peligro sólo permite la calificación relativa de los modos de fallo. Para que el proceso de puntuación sea lo más robusto posible, es importante que el equipo de HFFMEA califique los peligros como un grupo y que cualquier desacuerdo se discute hasta que se alcance un consenso. La dinámica del equipo también se debe considerar para evitar una situación en la que algunos individuos tienen una fuerte influencia en la puntuación. Además, el mismo equipo debe puntuar todos los peligros para la consistencia a través del análisis, en lugar de tener diferentes miembros del equipo calificando diferentes grupos de modos de fallo. El proceso de puntuación de riesgo sólo debe utilizarse para ayudar al equipo de HFFMEA a separar los modos de fallo de alto y bajo riesgo en relación entre sí y no como una medida absoluta o cuantitativa del riesgo en cada etapa del proceso.

Sección 9.7.4. Potencial para Falso Positivos

La forma en que se realiza la puntuación para un FMEA tradicional significa que es posible que un modo de fallo de alta severidad y baja probabilidad produzca el mismo puntaje de riesgo que un modo de fallo de baja gravedad pero alta probabilidad. Esto puede ser problemático en el cuidado de la salud porque al evaluar los riesgos a la seguridad del paciente, es probable que un modo de fallo que es improbable, pero de alta gravedad, requiera más atención que un modo de fallo que es probable pero bajo en gravedad. Incluso un problema serio de seguridad del paciente es todavía uno demasiado, y por lo tanto debe hacerse hincapié en este tipo de análisis. Para ayudar a resolver este desafío, el HFFMEA hace uso de un proceso de clasificación que incorpora cada modo de alto grado de fallo para una mayor consideración, independientemente de la frecuencia con la que pueda suceder.

Sección 9.7.5. No hay orientación para el desarrollo de estrategias de mitigación

Los métodos FMEA tradicionales no proporcionan ninguna orientación para el desarrollo de estrategias de mitigación eficaces para abordar los modos de fallo identificados. Como tal, corresponde al equipo de análisis proponer soluciones que permitan evitar con éxito la ocurrencia de modos de fallo. Además, el esfuerzo real requerido para implementar una estrategia de mitigación propuesta y el puntaje de peligro atribuido a un modo de fallo no siempre coinciden, lo que significa que a veces la puntuación indicará la necesidad de acción, pero el costo y el esfuerzo requeridos no están justificados por el riesgo. Para ayudar a sopesar los beneficios y los costos, así como establecer las expectativas sobre la probabilidad de una solución es mitigar un modo de fallo, el HFFMEA incorpora una jerarquía que se puede utilizar para evaluar la eficacia probable de una solución.

142

Sección 9.8. Recursos adicionales

Artículos periodísticos

1. ECRI. (2004). Failure mode and effects analysis: A hands-on guide for healthcare

facilities. Health Devices. 33(7); pp.233-243.

2. De Rosier J, Stalhandske E, Bagian JP, Nudell T. (2002). Using health care failure

mode and effect analysisTM: The VA National Centre for Patient Safety’s

prospective risk analysis system. Journal of Quality Improvement. 28(5); pp.

248-267.

Herramientas Web

1. Instituto de Mejora de la Salud Modos de falla y herramienta de análisis de efectos.

Http://www.ihi.org/knowledge/Pages/Tools/FailureModesandEffectsAnalys

isTool.aspx

143

Capítulo 10 Factores Humanos y Análisis Informado de Causa Raíz

Sección 10.1. Preparando el escenario

El Análisis de Causa Raíz (RCA) es un marco retrospectivo de investigación de incidentes, inicialmente desarrollado como una herramienta de ingeniería de gestión de calidad, que ahora se utiliza ampliamente en muchas industrias para apoyar la mejora de la seguridad de los sistemas después de un accidente o incidente. En el ámbito de la asistencia sanitaria, los organismos reguladores como la Joint Commission han encargado la investigación y la respuesta inmediatas tras un evento centinela, que es "un suceso inesperado que implica la muerte o lesiones físicas o psicológicas graves o el riesgo de ello" [44]. RCA es un medio por el cual este tipo de investigación y respuesta se puede lograr.

Al igual que los otros métodos de factores humanos presentados en este manual, un principio central de RCA es que en la asistencia sanitaria, inherentemente las personas no quieren causar daño. En consecuencia, este método se centra en identificar los factores del sistema y los problemas que contribuyen a un incidente, en lugar de lo que una persona podría haber hecho mal. Las causas raíz inherentes al sistema, y no a las personas, son los factores que deberán abordarse para mejorar la seguridad general del sistema. Cuando se culpa a los individuos por un incidente, la acción correctiva tiende a centrarse en la persona o personas involucradas, pero esto representa una oportunidad perdida de hacer cambios de alcance más amplio al sistema, dirigidos a prevenir sucesos futuros del mismo o un error similar. Desafortunadamente, hay muchos ejemplos de profesionales de la salud que involuntariamente cometieron errores como resultado de un diseño pobre del sistema y que han recibido duros castigos como perder su licencia profesional o ser acusados penalmente [45, 46]. Estos castigos se suman a la culpa, la angustia mental, y la pérdida de confianza en sí mismo experimentados como una "segunda víctima" del incidente [47, 48]. En el caso de una de esas segundas víctimas culpada por una sobredosis accidental de cloruro de calcio que condujo a la muerte de un paciente de ocho meses de edad, el estrés emocional de las secuelas del incidente la llevó a suicidarse [49].

Estos tipos de resultados trágicos para el personal involucrado en un incidente no son inevitables. En lugar de asignar la culpa, si uno aplica los sistemas de pensamiento y ve un incidente como una serie de fallos del sistema que en última instancia contribuyen a un evento centinela, identificar y hacer frente a los fallos del sistema servirá para fortalecer el sistema y mejorar la probabilidad de que futuros incidentes similares sean eliminados.

Para apoyar la conclusión de un RCA varias organizaciones de calidad y seguridad, tales como la Comisión Conjunta, el Centro Nacional de Administración de Veteranos para la Seguridad del Paciente, ISMP Canadá, el Instituto Canadiense de Seguridad del Paciente y el NHS (Reino Unido) han desarrollado diferentes marcos y herramientas de RCA. Por ejemplo, la Comisión Conjunta ofrece un marco de RCA en línea, junto con publicaciones sobre eventos centinela específicos que se han investigado utilizando RCA [50]. Además, la VA tiene herramientas en línea y tarjetas de triaje [51], ISMP Canadá ha publicado varias investigaciones de RCA de alto perfil [52], ISMP Canadá y CPSI han escrito conjuntamente el

144

Marco de Análisis de Incidentes Canadiense [53] y el NHS (Reino Unido) tiene un Online Rootkit Analysis Toolkit y eLearning Program [54].

Para los fines de este manual, se combinarán partes de estos marcos de RCA y se incorporarán varios métodos de factores humanos para crear un marco de HFRCA.

Sección 10.2. ¿Qué es HFRCA?

HFRCA es un método de análisis de factores humanos utilizado para identificar retrospectivamente causas raíz y factores que contribuyen a un incidente. Una causa raíz puede considerarse un factor iniciador que conduce a un efecto o resultado particular y un factor contribuyente puede considerarse una condición que influye en un efecto o resultado particular. Idealmente, un equipo multidisciplinario trabaja en conjunto para recolectar información, documentar el incidente, identificar las causas raíz y factores contribuyentes, e identificar estrategias de mitigación dirigidas a mejorar el sistema para prevenir que incidentes similares ocurran de nuevo.

El HFRCA tiene como objetivo mejorar el método más tradicional de RCA incorporando una gama de métodos de factores humanos durante el análisis para:

Determinar si un HFRCA debe ser realizado

Promover la recolección de datos y artefactos precisos y de calidad en el campo

de manera discreta

Documentar los eventos previos al evento centinela

Habilitar la identificación de las causas raíz desde una perspectiva de factores

humanos teniendo en cuenta nuestras fortalezas y limitaciones humanas

naturales

Identificar estrategias de mitigación informadas de factores humanos y establecer

expectativas sobre cuánto riesgo es probable que se mitigue dadas las soluciones

propuestas

Sección 10.3. ¿Por qué usar HFRCA?

Después de un evento centinela, o una falta cercana que podría haber impactado negativamente la seguridad del paciente, se debe realizar un HFRCA para examinar e identificar las causas raíz que contribuyeron al evento. Completar un HFRCA se recomienda fuertemente porque este método permite que el profesional biomédico de la tecnología vaya más allá de los factores que contribuyen a nivel superficial, a las causas subyacentes verdaderas de la raíz del problema. Sólo cuando se abordan las verdaderas causas raíz que se puede lograr una mejora fiable de la seguridad. Estos factores que contribuyen más a nivel superficial, llamados fallos activos, tienden a centrarse en las acciones de una persona y son altamente dependientes del contexto del incidente específico. Cuando una investigación se detiene aquí, significa que cuando otras personas se encuentran en la misma situación o una situación similar, el evento centinela es probable que se repita porque los factores del

145

sistema que estaban en su lugar durante el incidente, todavía existen. En contraste, cuando la causa raíz subyacente, también llamados fallos latentes, pueden ser identificados y abordados, el diseño del sistema es inherentemente mejorado para apoyar al personal a desempeñarse de manera segura, lo que hace que la ocurrencia de un evento centinela similar sea improbable.

Cuando se hace bien, un HFRCA puede unir al personal de toda la organización que ha sido impactada por un incidente de seguridad del paciente. La cultura organizacional se puede fortalecer cuando el personal trabaja en conjunto para identificar las causas raíz que contribuyeron a un incidente, lo que puede conducir a una fuerte determinación entre los miembros del personal para mejorar el sistema con el fin de promover la seguridad del paciente.

Desde la perspectiva del profesional de la tecnología biomédica, completar un HFRCA será útil para:

Evitar que los eventos centinela similares se repitan

Examen retrospectivo y manejo de las causas raíz que contribuyen a un evento

centinela

Examinar y manejar de forma retrospectiva las causas raíz que contribuyen a una

fallo cercano

Cumplimiento de los requisitos de acreditación tras un incidente

Sección 10.4. Cuándo usar HFRCA

Un HFRCA se debe conducir después de un evento centinela, un incidente que dio lugar a daño serio o muerte, o a una falta cercana que podría haber dado lugar al daño serio del paciente. Completar un HFRCA en una falta cercana seria que fue capturada puede ser una excelente oportunidad para prevenir de manera proactiva que ocurran otros eventos similares.

Antes de llevar a cabo un HFRCA, el profesional de la tecnología biomédica debe asegurarse de que tienen el apoyo y respaldo de la Administración para aumentar las posibilidades de absorción y los cambios positivos derivados del análisis. En el caso de una falta cercana, aunque un HFRCA no puede ser requerido desde la perspectiva de un órgano regulador, un caso fuerte todavía se puede hacer basado en la responsabilidad asociada a un posible futuro evento centinela con un historial de fallos cercanos.

Completar un HFRCA después de un incidente puede ser una experiencia catártica para los involucrados, brindando una oportunidad para fortalecer la cultura del lugar de trabajo y unir al personal ante una tragedia.

146

Sección 10.5. En preparación para un HFRCA

Hay poco que se puede hacer en la preparación para un HFRCA. A menudo, los eventos centinela parecen ocurrir repentinamente, por lo que el mejor enfoque es estar familiarizado con el marco del HFRCA y estar preparado para trabajar con líderes senior y actuar con rapidez una vez que ocurra un incidente.

Sección 10.6. Completar un HFRCA

El proceso HFRCA comprende seis pasos, esbozados en la Figura 25. Cada paso será presentado y descrito en esta sección.

Figura 25. Los seis pasos y oportunidades para incorporar factores humanos como parte de un HFRCA

Sección 10.6.1. Determinar si se requiere un HFRCA

Después de un evento centinela, el primer paso es determinar si se requiere un HFRCA. Esto debe hacerse lo más rápido posible para aumentar la posibilidad de recoger todo el equipo, suministros y tanta información como sea posible desde el lugar del incidente antes de que cualquier cosa sea ajustada o removida por otros.

Como se señaló anteriormente, deberá determinarse si el incidente es considerado o no intencional. Para ayudar con esta determinación, un Árbol de Decisión de Incidentes desarrollado por el NHS (Reino Unido) [55] y adaptado para este texto (Figura 26) debe ser utilizado. El árbol de decisiones es una herramienta que guía el proceso de determinar si un individuo o el sistema es culpable por un evento centinela.

147

Para aplicar el árbol de decisiones de incidentes, cada una de las cuatro pruebas de la Figura 26 debe aplicarse secuencialmente. Si las acciones fueron como se pretende y / o hay evidencia de mala salud o abuso de sustancias, el incidente puede haber provenido de una acción voluntaria, y no es un buen candidato para el análisis utilizando HFRCA. En estos casos, consulte con los organismos reguladores apropiados y los representantes sindicales, si procede, y considere cómo la situación será manejada por la organización sanitaria.

Figura 26. Árbol de decisión de incidentes para responder a eventos de seguridad del paciente. Reimpreso con permiso (adaptado del Servicio Nacional de Salud del Reino Unido).

Acción deliberada Prueba de daño deliberado SI

Fueron las acciones como se planearon?

Acción deliberada Prueba de Incpacidad

SI

Evidencia de enfermedad o abuso de sustancias?

N

O

El sujeto se alejó de el protocolo acordado o del procedimiento seguro?

Prueba de Previsión

SI Los protocolos y procedimientos eran disponibles, inteligibles y usados como rutina?

Prueba de Sustitución

NO

Otro individuo tendría el mismo comportamiento en circunstancias similares?

Acción no intencional – falla debida a factores del sistema

Alguna deficiencia en la capacitación, experiencia o supervision?

S

I

S

I

SI

NO

NO

NO

SI SI

148

Si las acciones del individuo no fueron como se habían previsto y no hay evidencia de mala salud o abuso de sustancias, se aplica la prueba de previsión. En los casos en que un individuo se apartó de un protocolo acordado o de un procedimiento seguro, es importante considerar si (1) los protocolos y procedimientos tienen sentido, (2) se usaron fácilmente y (3) estaban fácilmente disponibles para el personal. Recuerde que dado lo que sabemos acerca de las limitaciones humanas inherentes, tratar de influir en el comportamiento escribiendo las acciones esperadas en un protocolo no es una estrategia muy robusta para prevenir errores.

La prueba final requiere que el profesional de la tecnología biomédica considere si es probable que otro individuo en circunstancias similares se comporte de la misma manera. Es importante abordar esta pregunta final desde una perspectiva de factores humanos, es decir, considerar los factores del sistema que pueden haber llevado a alguien a comportarse de cierta manera. Tenga en cuenta nuestras limitaciones humanas inherentes (Capítulo 3) y considere si puede haber alguna deficiencia en el entrenamiento, la experiencia o la supervisión. En la mayoría de los casos, los profesionales de la tecnología biomédica encontrarán que los eventos centinela son el resultado de acciones involuntarias que conducen a fallos del sistema, en lugar de acciones deliberadamente nocivas.

Cuando el árbol de decisiones de incidentes señala una acción no intencional que resulta en uno fallo, indica que es el sistema que ha fallado. Estos tipos de eventos son buenos candidatos para el análisis utilizando un HFRCA. En estos casos, la institución de salud tendrá que determinar si el evento centinela avanzará para la investigación usando un HFRCA. Esta decisión probablemente se basará en muchos factores, incluyendo requisitos legislativos, estándares de acreditación, políticas de hospitales y recursos. Dado que la realización de un HFRCA puede ser un recurso intensivo, este tipo de iniciativa es más probable que se apoya cuando la organización está obligada a realizar este tipo de análisis.

Sección 10.6.2. Asegure artículos

Tan pronto como se ha tomado la decisión de avanzar con un HFRCA, es crítico que todos los artículos usados en el momento del incidente, y cualquiera usado poco antes, sean recolectados y asegurados. Si se trata de una tecnología, el dispositivo debe ser inmediatamente retirado de uso y los registros retenidos para asegurar que esta información esté disponible para el equipo en el futuro. Otras cosas para recopilar pueden incluir, pero no se limitan a:

Todos los medicamentos y líquidos, incluidos los envases y los objetos

punzocortantes

Copias de pedidos de medicamentos

Etiquetas de medicamentos

Papel de desecho usado para cálculos

Cualquier otro suministro y embalaje

Fotografías del medio ambiente

Fotografías de la configuración de la tecnología

149

Imágenes de pantalla de cualquier sistema electrónico

Historia Clínica del paciente

Si se obtiene la historia clínica del paciente, haga una copia para que la unidad continúe usándola si el paciente está recibiendo atención continua y asegúrese de seguir todas las normas de privacidad al manejar el registro de salud. La información sobre la unidad, como un horario, cambios de turno, nuevos procedimientos, cambios en equipos o suministros, prácticas organizacionales y políticas también pueden ser muy valiosas si están disponibles.

Una vez que estas cosas se han recogido del campo de uso de la tecnología, una fotografía debe ser tomada de cada artículo y todos los números de lote, números de serie, y fechas de vencimiento se deben registrar. Los artículos deben ser revisados, y el profesional de la tecnología biomédica debe considerar si hay evidencia de elementos que son inherentemente confusos, complicados o que parecen estar fuera de lo que se consideraría un procedimiento normal (por ejemplo, cambios manuscritos a una orden, medicamentos que se parecen o suenan igual). Cualquiera de estos tipos de observaciones se debe anotar para referencia futura.

Es importante recopilar y documentar esta información (por ejemplo, a través de fotografías y registros escritos) de manera oportuna para asegurar que sea lo más preciso posible, ya que en situaciones especialmente estresantes, los seres humanos tienen limitaciones inherentes a la memoria.

Sección 10.6.3. Establecer el equipo

Una vez que se han obtenido y asegurado los artículos del campo, se debe establecer un equipo de análisis básico para llevar a cabo el HFRCA. Los miembros del equipo deben estar bien informados sobre uno o más temas relacionados con el evento centinela, ser analíticos y tener una mentalidad que respalde una cultura justa donde las organizaciones de atención de la salud son responsables de los sistemas que han diseñado y el personal es responsable de sus opciones de comportamiento y por reportar errores y vulnerabilidades del sistema [56, 57]. Los miembros del equipo central deben participar en el curso del análisis completo, pero otros pueden participar como miembros del equipo según sea necesario para apoyar ciertos aspectos del análisis. Por ejemplo, los pacientes y miembros de la familia, y algunos expertos de la materia, sólo pueden estar involucrados mientras se está desarrollando una comprensión inicial del incidente. Así, el tamaño del equipo más grande variará no sólo dependiendo del contexto del incidente, sino también de la etapa del análisis.

En general, los equipos deben ser multidisciplinarios, incluyendo personal clínico y no clínico, para representar una amplia gama de perspectivas, y para proporcionar información valiosa y liderazgo para apoyar el análisis.

150

Sección 10.6.3.1 Completar un Acuerdo de Confidencialidad

Dependiendo de las políticas de su organización de salud, los miembros del equipo pueden tener que firmar un acuerdo de confidencialidad antes de participar como parte de un equipo de HFRCA. Firmar este tipo de acuerdo puede servir como un recordatorio de la responsabilidad de los miembros del equipo de proteger cualquier información obtenida como parte de la HFRCA. El Marco Canadiense de Análisis de Incidentes [53] proporciona un ejemplo de acuerdo de confidencialidad en caso de que su organización sanitaria no tenga una plantilla preparada.

Sección 10.6.3.2 Funciones de los miembros del equipo

Los miembros individuales del equipo tendrán que cumplir una serie de funciones para asegurar un HFRCA exitoso. Estas funciones incluyen un líder, un facilitador y un representante de alto nivel de liderazgo. Además, necesitará expertos en la materia que estén bien informados y puedan proporcionar información y pensar críticamente sobre los factores del sistema que pueden haber llevado al evento centinela, tales como tecnologías, procesos, factores ambientales, políticas, programas de capacitación, cambios organizacionales, etc. Un miembro del equipo debe asumir el papel de secretario, e idealmente, un experto en factores humanos también debe ser incluido como parte del equipo de HFRCA.

Finalmente, dependiendo de su institución, es posible que desee comunicarse con el paciente y su familia para ver si están dispuestos a participar como parte del equipo de HFRCA. Los pacientes y los miembros de la familia pueden proporcionar una perspectiva esencial que será única y diferente de la de cualquiera de los miembros del equipo clínico. Además, la participación de pacientes y miembros de la familia puede proporcionar un sentido necesario de cierre y contribución en algunos casos. Sin embargo, es esencial señalar que puede ser difícil incluir a aquellos que estuvieron directamente involucrados en el incidente, ya sean pacientes y miembros de la familia o el personal, y deberán ser abordados con extrema sensibilidad para asegurar que la experiencia sea positiva y no defensiva o punitiva.

Líder del equipo

De acuerdo con el Marco Canadiense de Análisis de Incidentes [53], un líder es alguien que tiene una comprensión general del incidente ocurrido y tiene la autoridad para emprender una investigación. Un individuo en un alto cargo de gestión clínica que posee fuertes habilidades clínicas y analíticas sería un buen candidato. El líder será responsable de:

Mantener al equipo enfocado

Apoyar el cambio cultural

Apoyar a otros miembros del equipo en su análisis

Eliminar las barreras encontradas por otros miembros del equipo

Facilitador

Un facilitador es alguien que puede manejar dinámicas de grupo, delegar tareas y facilitar la construcción de consenso de grupo. Un individuo que es un especialista en calidad

151

o gestión de riesgos, que posee confianza y tiene experiencia en métodos analíticos, sería un candidato fuerte. El facilitador será responsable de:

Reuniones de los equipos de coordinación

Asegurar que el equipo permanezca enfocado

Facilitar la discusión constructiva entre los miembros del equipo

Vigilancia de plazos

Asegurar que el proceso de análisis siga el protocolo y las políticas de la

organización sanitaria

Asegurar la realización de un informe final, si corresponde

Representante de Liderazgo Senior

Un representante de alto nivel de liderazgo es alguien que tiene la autoridad para tomar decisiones y ayuda a impulsar una cultura de seguridad. Un individuo que es un directivo senior de la Organización será un candidato fuerte. El representante de la alta dirección será responsable de:

Asegurar que cualquier acción y estrategias de mitigación sean implementadas

Autorizar el tiempo programado fuera de las funciones regulares del miembro del

personal para participar en el análisis

Fomentar y apoyar la amplia comunicación de los resultados y las estrategias de

mitigación

Asegurar que los involucrados en el evento centinela, incluidos los pacientes y las

familias, y el personal, sean apoyados para que la experiencia sea lo más positiva

posible

Expertos en la materia

Los expertos en la materia son individuos que conocen bien uno o más temas relacionados con el evento centinela. Deben tener una comprensión detallada de cualquier tecnología, proceso, entorno, política, entrenamiento y estructuras organizacionales o cambios que puedan haber contribuido al incidente. Los expertos en la materia deben ser pensadores críticos, capaces de proporcionar retroalimentación e información sobre el curso de la HFRCA. Estos miembros del equipo llevarán a cabo la mayor parte del análisis práctico, incluyendo el desarrollo de una comprensión inicial del incidente, la identificación de las causas raíz y los factores que contribuyen, y el desarrollo de estrategias de mitigación.

Secretario

El secretario es responsable de capturar cualquier discusión o decisiones tomadas cuando el equipo se reúne. El secretario debe distribuir las minutas de reunión a todo el equipo y una agenda de lo que el equipo espera lograr antes de cada reunión.

Experto en factores humanos

Idealmente, el equipo de HFRCA incluirá al menos un experto en factores humanos. La perspectiva de los factores humanos es importante para un HFRCA porque esto facilitará

152

la inclusión de varios métodos de factores humanos y asegurará que el análisis tome en cuenta nuestras limitaciones humanas inherentes, especialmente cuando se piensa en las causas raíz y los factores contribuyentes al evento centinela. Si no es posible incluir a un experto en factores humanos, el profesional de la tecnología de la salud puede aplicar el nuevo conocimiento de los factores humanos (respaldado por este libro y los recursos adicionales destacados en este libro) durante el HFRCA para cumplir este rol. Otra opción más rentable a considerar es traer a un estudiante graduado de factores humanos y su asesor para ayudar a proporcionar esta visión, si está disponible.

Paciente y familia

Si el paciente y la familia están incluidos como parte del equipo de HFRCA, podrán proporcionar información invaluable sobre el evento centinela desde una perspectiva única que ningún otro miembro del equipo tendrá. Servirán como expertos de la materia desde la perspectiva de los que reciben atención.

Sección 10.6.4. Desarrollar una comprensión inicial del incidente

Desarrollar una comprensión inicial completa y exacta del incidente será clave en el apoyo a la identificación de las causas raíz reales y factores contribuyentes y el desarrollo de estrategias de mitigación robustas y efectivas.

Sección 10.6.4.1 Creación de un diagrama de flujo de proceso inicial

Para comenzar, cree un diagrama de flujo de proceso (Capítulo 6) basado en su comprensión preliminar del incidente. Esta comprensión inicial debe ser informada con cualquier información recolectada del personal involucrado, la información de cualquier informe de incidente, registros históricos de cualquier dispositivo, cualquier información que se pueda obtener de los sistemas hospitalarios y artefactos. El objetivo definido para este análisis de tareas debe coincidir con el de las personas en el momento del evento centinela. El alcance de este análisis de tareas también debe coincidir con las condiciones y contexto presentes en el momento del evento centinela. El diagrama de flujo del proceso inicial debe describir el proceso real más que el proceso y la secuencia de eventos prescritos.

A medida que se está creando el diagrama, mantenga un registro de las preguntas que surjan o áreas de incertidumbre, ya que éstas tendrán que ser tratadas a medida que el diagrama se actualiza iterativamente.

Sección 10.6.4.2 Actualizar Iterativamente el Diagrama de Flujo de Proceso

Una vez que este diagrama inicial se ha creado para describir la secuencia de eventos, es esencial que el diagrama se comparta con el equipo HFRCA para obtener cualquier retroalimentación. Al igual que con cualquier análisis de tareas, la creación de un diagrama de flujo de proceso es iterativo, requiriendo múltiples rondas de intercambio, incorporando retroalimentación y revisión. Para apoyar el método HFRCA, además de compartir el diagrama con el equipo de HFRCA para retroalimentación, observaciones (Capítulo 4), y entrevistas (Capítulo 5) también deben hacerse para mejorar aún más el diagrama de flujo del proceso. Una vez que se han completado varias rondas de iteración y el diagrama refleja el flujo de trabajo real durante el evento centinela lo más cerca posible, el diagrama puede

153

considerarse completo. En el caso de que aparezca información nueva, este diagrama debe actualizarse sin importar en qué punto del HFRCA esté el equipo, para asegurar que el diagrama refleje la información más precisa posible.

Sección 10.6.4.3 Capa con Otra Información Contextual en el Diagrama de Flujo de Proceso

Este diagrama de flujo del proceso puede ser utilizado como la columna vertebral para desarrollar una comprensión inicial del incidente. Además de una visión general de las tareas que conducen al evento centinela, este diagrama también puede usarse para documentar el calendario de varias tareas y eventos, y como un texto o clave para vincular a artefactos, políticas, procedimientos y otra información contextual que se recopiló cuando los elementos fueron asegurados.

El profesional de la tecnología biomédica también puede encontrar útil indicar no sólo los eventos reales que llevan al evento centinela, sino también el "proceso de trabajo esperado" y el "proceso de trabajo típico" para que cualquier desviación pueda ser destacada. El proceso de trabajo esperado es la serie de pasos que deben ser llevados a cabo por el personal como se describe en las políticas y procedimientos de una organización sanitaria. El proceso de trabajo típico es la serie de pasos que la mayoría del personal lleva a cabo como resultado de la realidad de las operaciones diarias, incluyendo factores como las presiones del trabajo, el tiempo y de costos. Es probable que los procesos de trabajo esperados y típicos difieran, ya que los procesos de trabajo típicos incluirán cosas como soluciones y accesos directos que la mayoría del personal usará para tratar de realizar su trabajo de la manera más eficiente y segura posible. La adición de información sobre los procesos de trabajo esperados y típicos al diagrama de los eventos reales que conducen al evento centinela puede ser extremadamente útil porque cualquier punto en el que hay desviaciones sirven como pistas de que el sistema como está diseñado no está apoyando a las personas que trabajan en él. Las políticas y procedimientos que se han desarrollado pueden parecer correctos en el papel, pero cuando se tienen en cuenta el contexto y la realidad de las líneas de frente, las políticas y los procedimientos pueden ser complicados de seguir.

Sección 10.6.4.4 Finalizar el Diagrama de Flujo del Proceso

Una vez creado el diagrama, actualizado iterativamente y utilizado como base para vincular artefactos y otra información contextual, incluyendo cualquier desviación de los flujos de trabajo esperados y típicos, se debe distribuir al equipo principal del HFRCA para cualquier retroalimentación adicional. Este diagrama se utilizará como base para identificar las causas raíz y los factores contribuyentes que conducen al evento centinela.

Sección 10.6.4.5 Crear una descripción factual de los eventos que conducen al incidente

Basándose en el diagrama de flujo del proceso finalizado, se debe crear una descripción escrita y factual de los eventos que condujeron al evento centinela. Esta descripción será más accesible para el personal que está fuera de los equipos nuclear y ampliado del HFRCA cuando es el momento de compartir información sobre el incidente con ellos.

154

Sección 10.6.5. Identificar factores contribuyentes

Una vez que el equipo tiene una clara comprensión inicial de lo que ocurrió antes del incidente, el paso siguiente y más importante de un HFRCA es entender las causas raíz y los factores que contribuyen a porqué ocurrió el incidente. Es importante señalar que un evento centinela es casi siempre causado por múltiples factores, en lugar de una causa raíz única. La causa raíz se considera típicamente el primer eslabón en una cadena de factores que contribuyen al incidente. Los factores contribuyentes pueden considerarse circunstancias, acciones u otros factores influyentes que probablemente hayan desempeñado un papel o aumentado la probabilidad de que ocurra el incidente [53].

Un punto de partida útil cuando se identifican causas puede ser anotar la tarea o acción que salió mal, y luego seguir preguntando por qué falló al usar el diagrama de flujo del proceso y cualquier artefacto a medida que avanza. Este enfoque permitirá al equipo construir una comprensión del contexto del sistema que rodeó el incidente. En este punto ya se habrá establecido que los individuos involucrados en el evento centinela no tenían la intención de causar daño, como es el caso de HFFMEA, es importante evitar centrarse sólo en las causas centradas en el ser humano y en fallos de los individuos para cumplir con los protocolos y procedimientos establecidos (Sección 13.2.6). Si un individuo comete un error o no cumple con un protocolo o procedimiento establecido, el trabajo del equipo de HFRCA es preguntar por qué podría haber sido. Los sistemas en los que trabajamos no deben exigir que seamos sobrehumanos, sino que los sistemas deben diseñarse para tener en cuenta nuestras limitaciones humanas. Las características de un sistema que no nos apoyan en nuestras fortalezas y limitaciones inherentes tienen el potencial de llevarnos a cometer errores, y por lo tanto deben ser pensados como factores contribuyentes.

Sección 10.6.5.1 Marco del Modelo Humano-Técnico / Queso Suiza

Para ayudar a identificar las características del sistema que contribuyen a un evento centinela, se pueden utilizar varios métodos de factores humanos, tales como observaciones (capítulo 4), entrevistas (capítulo 5), heurística (capítulo 7) o pruebas de usabilidad (capítulo 8). Además, se recomienda encarecidamente una combinación de la escalera de tecnología humana (sección 3.2) y el modelo de error de queso suizo de Reason (sección 3.4) como herramienta de guía (figura 27).

155

Figura 27. Marco de factores humanos adaptado del modelo de queso suizo de Reason, 2000 y Escala Human-tech de Vicente, 2004

Este marco de factores humanos ilustra la importancia de pensar más allá de las causas centradas en el ser humano, para pensar en factores contribuyentes relacionados con los niveles físico, psicológico, de equipo, organizativo y político del sistema. Los factores latentes en cada uno de estos niveles suelen traducirse en debilidades del sistema que pueden combinarse para permitir que ocurra un evento centinela. Por ejemplo, si un equipo de HFRCA está tratando de identificar los factores contribuyentes que conducen a un incidente en el que se hizo un error de cálculo que condujo a una sobredosis al paciente, el marco de factores humanos adaptado podría ser utilizado como sigue (Figura 28).

156

Figura 28. Usando el modelo de Queso Suizo de Reason y la escalera Human-tech de Vicente para identificar los factores que contribuyen a un evento centinela

Además del marco de factores humanos y de los otros métodos de factores humanos mencionados anteriormente (es decir, observaciones, entrevistas, heurísticas, pruebas de usabilidad), el cuadro 18 de la Joint Commission's RCA Framework ofrece una serie de sugerencias útiles para alentar la HFRCA para pensar a través de una amplia gama de posibles factores contribuyentes.

157

Tabla 18. Herramienta del Plan de Acción de RCA (© Joint Comission, 2013. Reimpreso con permiso.)

Preguntas de análisis Mensajes 1 ¿Cuál fue el flujo del proceso esperado?

Enumere las etapas de proceso relevantes definidas por la política, procedimiento, protocolo o directrices vigentes a la hora del evento. Es posible que deba incluir múltiples procesos.

Nota: Los pasos del proceso como ocurrieron en el evento se insertarán en la siguiente pregunta.

Ejemplos de pasos de proceso definidos pueden incluir, pero no se limitan a:

• Protocolo de verificación del sitio • Procedimientos de contar instrumentos, esponjas y elementos de afilados • Protocolo de identificación del paciente • Procedimientos de evaluación (dolor, riesgo de suicidio, procedimientos físicos y psicológicos) • Pautas de prevención de caídas y riesgo de caídas

2 ¿Hubo algún paso en el proceso que no ocurrió como se esperaba?

Explique en detalle cualquier desviación de los procesos enumerados en el Análisis # 1 anterior.

3 ¿Cuáles factores humanos fueron relevantes para el resultado?

Discuta los factores de rendimiento humano relacionados con el personal que contribuyeron al evento.

Los ejemplos pueden incluir, pero no se limitan a:

Aburrimiento

Incumplimiento de las políticas / procedimientos

establecidos

Fatiga

Incapacidad para concentrarse en la tarea

Sesgo de ceguera / confirmación no intencional

Problemas personales

Falta de habilidades complejas de pensamiento

crítico

Apresurarse para completar la tarea

Abuso de sustancias

Confianza

158

4 ¿Cómo afectó el rendimiento del equipo en el resultado?

Tenga en cuenta todo el equipo médico y los dispositivos utilizados en el curso de la atención al paciente, incluidos los dispositivos AED, carros de choque, la succión, el oxígeno, los instrumentos, los monitores, equipos de infusión, etc. En su discusión, proporcione información sobre lo siguiente, según corresponda:

• Descripciones de los controles biomédicos

• Disponibilidad y estado del equipo

• Descripciones de equipos con piezas múltiples o desmontables

• Ubicación del equipo y su accesibilidad al personal y a los pacientes

• Conocimiento del personal o capacitación sobre el equipo, incluyendo las competencias aplicables

• Calibración correcta, ajuste, operación de alarmas, pantallas y controles

5 ¿Qué factores ambientales controlables afectaron directamente el resultado?

¿Qué factores ambientales dentro del control de la organización afectaron el resultado? Los ejemplos pueden incluir, pero no se limitan a: • Paginación aérea que no se puede oír • Riesgos de seguridad o de seguridad • Riesgos que involucran actividades de visitantes • Problemas de iluminación o espacio La respuesta a esta pregunta se puede abordar más globalmente en la pregunta # 17.Esta respuesta debe ser específica para este evento.

6 ¿Qué factores externos incontrolables influyeron en este resultado?

Identifique los factores que la organización no puede cambiar y que contribuyeron a una fractura de los procesos internos, ejemplo los desastres naturales

7 ¿Hubo otros factores que influyeron directamente en este resultado?

Enumere cualquier otro factor aún no discutido.

8 ¿Cuáles son las otras áreas de la organización donde esto podría pasar?

Se enumeran todas las demás áreas en las que existe el potencial para circunstancias similares. Por ejemplo:

• Cirugía para pacientes internados / cirugía ambulatoria

159

• Atención psiquiátrica para pacientes internados / atención psiquiátrica ambulatoria

Identificación de otras áreas dentro de la organización que tienen el potencial de impactar la seguridad del paciente de una manera similar. Esta información ayudará a manejar el alcance de su plan de acción.

9 [Fueron] ... personal adecuadamente calificados y actualmente competentes para sus responsabilidades en el momento del evento?

Incluya información sobre lo siguiente para todo el personal y proveedores involucrados en el evento. Comente los procesos establecidos para asegurar que el personal es competente y calificado. Los ejemplos pueden incluir, pero no son limitados a:

• Entrenamiento de orientación

• Evaluación de competencias (¿Qué competencias tiene el personal y cómo las evalúa?)

• El alcance de las preocupaciones del proveedor y / o del personal fue acreditado y privilegiado por el cuidado y los servicios que prestó

• La política y procedimientos de acreditación y privilegio

• Problemas de rendimiento del proveedor y / o del personal

10 ¿Cómo se compara el personal con los niveles ideales?

Incluya los índices de cantidad de personal ideales y los índices reales de cantidad de personal junto con el censo de la unidad en el momento del evento. Anote cualquier circunstancia inusual que ocurrió en este momento. ¿Qué proceso se utiliza para determinar la proporción de personal del área de atención, el nivel de experiencia y la combinación de habilidades?

11 ¿Cuál es el plan para lidiar con contingencias de personal?

Incluir información sobre lo que hace la organización durante una crisis de personal, como llamadas para excusarse, mal tiempo, o agudización del paciente. Describa el uso de personal alternativo por parte de la organización. Los ejemplos pueden incluir, pero no están limitados a: • Enfermeras de agencia • Entrenamiento cruzado

160

• Equipo flotante de personal • Horas extraordinarias obligatorias • Equipo de personal por demanda (PRN)

12 ¿Fueron esas contingencias un factor en este evento?.

Si tales contingencias fueron utilizadas, describa su orientación hacia el área, la verificación de la competencia y familiaridad con el ambiente.

13 ¿El desempeño del personal durante el evento cumple con las expectativas?

Describa si el personal realizó como se esperaba en, o fuera de los procesos. ¿Hasta qué punto el liderazgo estaba al tanto de cualquier desviación de desempeño en ese momento? ¿Qué procesos de vigilancia proactiva existen para que el liderazgo identifique las desviaciones de los procesos esperados? Incluya omisiones en el pensamiento crítico y / o variación de desempeño de la política definida, el procedimiento, el protocolo y las pautas vigentes en ese momento.

14 ¿Hasta qué punto toda la información necesaria estuvo disponible cuando fue necesario? ¿Precisa? ¿Completar? ¿Sin ambigüedad?

Discutir si las evaluaciones de los pacientes fueron completadas, compartidas y consultadas por los miembros del equipo de tratamiento, para incluir a los proveedores, de acuerdo con los procesos organizacionales. Identificar los sistemas de información utilizados durante el cuidado del paciente. Discutir hasta qué punto la información disponible del paciente (por ejemplo, estudios de radiología, resultados de laboratorio o la historia clínica) fue clara y suficiente para proporcionar un resumen adecuado de la condición del paciente, el tratamiento y la respuesta al tratamiento. Describa la utilización del personal y la adecuación de la política, el procedimiento, el protocolo y las pautas específicas para la atención proporcionada al paciente.

15 ¿Hasta qué punto la comunicación entre los participantes es adecuada para esta situación?

El análisis de los factores relacionados con la comunicación debe incluir la evaluación de la comunicación verbal, escrita, electrónica o la falta de ella. Considere lo siguiente en su respuesta, según sea apropiado: El momento de la comunicación de la información

clave

161

Malentendidos relacionados con barreras

lingüísticas / culturales, abreviaturas,

terminología, etc.

Terminación adecuada de la comunicación interna

y externa

Participación del paciente, de la familia y / o de

otras personas

16 ¿Fue este el adecuado ambiente físico para los procesos que se llevan a cabo para esta situación?

Considerar procesos que gestionan de forma proactiva el entorno del paciente. Esta respuesta puede correlacionarse con la respuesta en la pregunta 6 sobre una escala global. ¿Qué herramienta o método de evaluación existe para evaluar las necesidades del proceso y mitigar los cuidados del paciente respecto a los riesgos ambientales? ¿Cómo se abordan estas necesidades de proceso en toda la organización? Los ejemplos pueden incluir, pero no se limitan a: • pruebas de audibilidad de alarma • evaluación de los puntos de salida • nivel de agudeza del paciente y configuración de la atención administrada a través del continuo, • preparación de medicamentos fuera de la farmacia

17 ¿Qué sistemas existen para identificar los riesgos ambientales?

Identificar evaluaciones de riesgos ambientales. • ¿El ambiente actual cumple con los códigos, especificaciones, reglamentos? • ¿Sabe el personal cómo informar los riesgos ambientales? • ¿Hubo un riesgo ambiental involucrado en el evento que no fue identificado previamente?

18 ¿Qué respuestas emergencia-fallo se han planificado y probado?

Describa las variaciones en el proceso esperado debido a una respuesta real de modo de emergencia o fallo en conexión con el evento. En relación con este evento, qué evaluaciones y simulacros de seguridad se han llevado a cabo y con qué frecuencia (por ejemplo, código azul simulado, respuesta rápida, emergencias de comportamiento, abducción del paciente o fuga del paciente)?

162

Las respuestas de emergencia pueden incluir, pero no se limitan a: Fuego

Desastre externo

Accidente de masa

Emergencia médica

Las respuestas de modo de fallo pueden incluir, pero no se limitan a: Tiempo de inactividad del equipo

Planificación de desviación

Construcción de instalaciones

Pérdida de potencia

Problemas de utilidad

19 ¿Cómo apoya la organización la reducción de riesgos?

¿Cómo fomenta la cultura general el cambio, las sugerencias y las advertencias del personal con respecto a situaciones de riesgo o áreas problemáticas? • ¿Cómo demuestra el liderazgo los valores culturales y de seguridad de la organización? • ¿Cómo se mide la cultura y la seguridad de la organización? • ¿Cómo establece el liderazgo métodos para identificar las áreas de riesgo o acceder a sugerencias de los empleados para el cambio? • ¿Cómo se implementan los cambios?

20 ¿Cuáles son las barreras para

comunicación de los posibles factores de riesgo?

Describa barreras específicas para la comunicación efectiva entre los cuidadores que han sido identificados por la organización. Por ejemplo, intimidación residual o renuencia a reportar la actividad de uncompañero de trabajoactividad.

Identifique las medidas que se están tomando para eliminar las barreras. Si no hay barreras para la comunicación, discuta cómo se sabe esto.

21 ¿Cómo se comunica la prevención de los resultados adversos como una prioridad?

Describa los procedimientos de resultado adverso de la organización y cómo el liderazgo desempeña un papel dentro de esos procedimientos.

163

22 ¿Cómo se puede revisar la orientación y la formación en servicio para reducir el riesgo de tales eventos en el futuro?

Describa cómo se evalúa la orientación y las necesidades de educación continua del personal y discute su relevancia para el evento. (Por ejemplo, competencias, habilidades de pensamiento crítico, uso de laboratorios de simulación, práctica basada en evidencia, etc.)

23 La tecnología disponible fue dada como se esperaba?

Los ejemplos pueden incluir, pero no se limitan a: • Equipos de tomografía computarizada • Cartografía electrónica • Sistema de suministro de medicamentos • Servicios de tele-radiología

24 ¿Cómo podría ser la tecnología introducida o rediseñada para reducir el riesgo en el futuro?

Describir los planes futuros de implementación o rediseño. Describir el sistema tecnológico ideal que puede ayudar a mitigar posibles eventos adversos a futuro.

Además del Marco del Modelo Humano-Técnico / Suizo de Queso (Figura 27) y de la

Herramienta de Plan de Acción de la Comisión Conjunta, el Marco de Análisis de Incidentes de Canadá esboza un conjunto de preguntas orientadoras que pueden alentar al equipo de HFRCA a identificar posibles factores contribuyentes en varios niveles del sistema (Tabla 19). Tabla 19. Preguntas orientadoras para apoyar la identificación de factores contribuyentes:

Tarea (proceso de cuidado / trabajo): • ¿Hubo fallos previos o previstos para esta tarea o proceso? • ¿Se requerían habilidades especializadas para realizar la tarea? • ¿Se requería un proceso fijo o una secuencia de pasos (por ejemplo, conjuntos de

órdenes, listas de verificación)? • ¿Existió y fue seguido? • ¿Había un protocolo disponible, actualizado y seguido en este caso? • ¿Había restricciones o presiones (por ejemplo, tiempo, recursos) al realizar la

tarea? • ¿La información requerida para tomar las decisiones de cuidado disponibles y

actualizadas (Por ejemplo, los resultados de las pruebas, la documentación, la identificación del

paciente)?

164

• ¿Había un programa de evaluación / auditoría / control de calidad en el lugar para la tarea / proceso?

• ¿Otro?

Equipos (incluidos los sistemas de información y comunicación): • ¿Las pantallas y los controles eran comprensibles? • ¿El equipo detectó y mostró automáticamente problemas? • ¿La pantalla era funcional? • ¿Las etiquetas de advertencia, la guía de referencia y los mecanismos de seguridad

eran funcionales y fácilmente visibles / accesibles? • ¿Se realizaron las actualizaciones y el mantenimiento? • ¿El equipo estaba estandarizado? • ¿Los usuarios describirían este equipo como "fácil de usar"? • ¿Los sistemas de comunicación (teléfono, buscapersonas, software, hardware) Disponibles y operacionales? • ¿Otro

Entorno de trabajo: • ¿Los niveles de ruido interfieren con las alarmas? • ¿La iluminación fue adecuada para la tarea? • ¿El área de trabajo fue adecuada para las tareas que se están realizando (por

ejemplo, espacio, disposición, ubicación y accesibilidad de los recursos)? • ¿Otro?

Características del (de los) paciente (s): • ¿El (los) paciente (s) tenía la información para ayudar a evitar el incidente? • Si no, ¿qué habría apoyado al paciente para ayudar a su equipo de atención? • ¿Contribuyeron al incidente factores como la edad, el sexo, los medicamentos, las

alergias, el diagnóstico u otras condiciones médicas? ¿Cómo contribuyeron? • ¿Hubo factores sociales o culturales que contribuyeron al incidente? • ¿Qué factores? ¿De qué manera? • ¿El lenguaje era una barrera? • ¿Otro?

2 Reimpreso del Marco de Análisis de Incidentes de Canadá. Copyright (2012) con permiso del Instituto Canadiense para la Seguridad del Paciente.

Equipo de cuidado: Cuidador (es): • ¿La educación, la experiencia, la capacitación y el nivel de habilidad eran

apropiados? • ¿Fue un problema la fatiga, los factores de estrés, la salud u otros factores? • ¿Fue adecuada la carga de trabajo? • ¿Se disponía de ayuda y supervisión adecuada y oportuna? • ¿Otro?

165

Equipo de atención: Equipo de apoyo (todos involucrados en el proceso de

atención): • ¿Hubo una comprensión clara de los roles y responsabilidades? • ¿La calidad y la cantidad de comunicación (verbal y / o escrita) entre los

miembros del equipo fueron apropiadas (claras, precisas, libres de jerga, relevantes, completas y oportunas)?

• ¿Hubo reuniones informativas periódicas del equipo sobre temas importantes de atención?

• ¿La moral del equipo era buena? ¿Se apoyan los miembros del equipo? • ¿Los canales de comunicación estaban disponibles y apropiados para soportar las

necesidades del equipo (por ejemplo, correo electrónico, buscapersonas y teléfono)? • ¿Otro?

Organización: Políticas y prioridades: • ¿Están disponibles las políticas y procedimientos pertinentes, conocidos,

accesibles y satisfacen las necesidades de los usuarios • ¿Existen soluciones provisionales a la política / procedimiento documentado? • ¿Existía un mecanismo para identificar y resolver las brechas entre la política y la

práctica? • ¿Las prioridades estratégicas de la organización fueron claras para todos? • ¿Otro?

Cultura de la organización: • ¿Fue todo el mundo (pacientes, clínicos, otro personal) cómodo para hablar sobre

preocupaciones de seguridad? • ¿Hubo un apoyo visible del liderazgo y del consejo para una atención segura del

paciente? • ¿La comunicación entre el personal y la administración apoyaba la atención

cotidiana del paciente al día a día? • ¿Se consideraron los incidentes como fallos del sistema con personas que no

fueron culpadas? • ¿Otro?

Organización: Capacidad (recursos): • ¿La programación influyó en el nivel de personal, o causó estrés, fatiga? • ¿Había suficiente capacidad en el sistema para desempeñarse eficazmente (por

ejemplo, el acceso a los recursos)? • ¿Fueron apropiados los incentivos formales y / o de incentivos? • ¿Otro?

166

Otros - considere: • ¿Existen condiciones o circunstancias locales que puedan haber influido en el

incidente y / o en un resultado? • ¿Existen condiciones o circunstancias específicas del sector que puedan haber

influido en el incidente y / o en el resultado? • ¿Otro?

Sección 10.6.5.2 Instrumentos Tradicionales de RCA para Documentar los Factores Contribuyentes

El equipo de HFRCA también puede encontrar otros tipos de diagramas útiles para documentar los factores contribuyentes identificados en diferentes niveles del sistema. Pueden utilizarse muchas herramientas y enfoques de documentación, pero se incluyen tres ejemplos a menudo utilizados como parte de un método RCA tradicional: el Diagrama de Ishikawa, el Diagrama de árbol y el Diagrama de constelación. Más detalles sobre estos diagramas están disponibles como parte Marco Canadiense de Análisis del Incidente.

Diagrama de Ishikawa4

Un diagrama de Ishikawa, nombrado por su "creador, también se conoce como diagrama de la espina de pez. Para crear este tipo de diagrama se dibuja una línea recta que termina en un recuadro que contiene el incidente (Figura 29). Las siguientes categorías que representan los factores contribuyentes están indicadas y conectadas a la línea recta que conduce al incidente (Figura 30). Finalmente, se analiza información más detallada sobre los factores contribuyentes en cada categoría de factor contribuyente (Figura 31). Los diagramas de Ishikawa generalmente no permiten un entendimiento claro del orden en que ocurren los factores contribuyentes, sino que proporcionan un medio para categorizar y resumir los factores que contribuyen de un vistazo.

Figura 29. Diagrama de Ishikawa: Línea recta que termina en un recuadro que contiene el incidente

Figura 30. Diagrama de Ishikawa: Categorías de factores contribuyentes

167

Figura 31. Diagrama de Ishikawa: Información detallada sobre factores contribuyentes por categoría

Diagrama de árbol

Un diagrama de árbol (Figura 32) es un diagrama de causa-consecuencia lineal que comienza con el incidente y crece hacia atrás a medida que las acciones o condiciones que conducen a la acción precedente están documentadas. A diferencia de los Diagramas de Ishikawa, los diagramas de árbol permiten que las cadenas causales sean denotadas, donde las causas y efectos respectivos de una serie de acciones se pueden rastrear desde la causa raíz hasta el incidente. En la mayoría de los casos sin embargo, los diagramas de árbol serán demasiado simplistas como una herramienta de documentación porque en realidad, los incidentes resultan de múltiples factores contribuyentes, en lugar de una relación de causa a efecto uno a uno.

Figura 32. Diagrama de árbol

168

Diagrama de Constelación

Un diagrama de constelación (Figura 33) es una herramienta de documentación más versátil que el diagrama de Ishikawa o diagrama de árbol que permite categorizar e ilustrar las relaciones causales entre todos los factores contribuyentes identificados.

Figura 33. Diagrama de constelación

Este tipo de diagrama será probablemente el más útil para el profesional de la tecnología biomédica una vez que se haya aplicado el modelo de Modelo de Humano-Técnico / Queso Suizo (Figura 27), ya que los niveles de la escala de Tecnología Humana pueden ser usados como categorías y las relaciones causales entre factores contribuyentes pueden ser indicadas de una manera flexible (Figura 33). Con un diagrama de constelación, cada factor contribuyente debe conectarse al menos otro factor o una categoría de factores. Si un factor contribuyente no se conecta a otro factor o a una categoría, deberá crearse una nueva categoría o el factor no pertenecerá al análisis.

Sección 10.6.5.3 Finalizar la Documentación de los Factores Contribuyentes

Una vez que se han identificado y documentado las causas raíz y factores contribuyentes, el análisis debe ser compartido con el equipo de HFRCA para recopilar

169

cualquier tipo de retroalimentación. A medida que se revisa el análisis, el equipo de HFRCA debe considerar tres preguntas principales:

¿Cuáles son los factores que:

1. Si se hubieran corregido, habrían evitado el incidente o mitigado el daño?

2. Si se hubieran corregido, NO habrá evitado el incidente o mitigado el daño, pero sigue siendo importante para mejorar la seguridad del paciente y / o del personal en general?

3. ¿Prevendrían que el incidente tuviera consecuencias más graves y, por lo tanto, representaran salvaguardias que deberían permanecer en su lugar?

Independientemente del enfoque para documentar los factores que contribuyen, estas tres preguntas deben ser usadas como base para priorizar qué factores justifican la consideración y desarrollo de recomendaciones y estrategias de mitigación.

Sección 10.6.6. Desarrollar estrategias de mitigación

Después de que se hayan identificado, documentado y priorizado las causas raíz y factores contribuyentes que condujeron al incidente utilizando las tres preguntas de la Sección 10.6.5.3, deberán desarrollarse estrategias de mitigación. Dado que la mayoría de las organizaciones de salud tienen recursos limitados, una selección, en lugar de cada causa raíz y factor contribuyente, terminará siendo abordada. El número y tipos de estrategias mitigadoras implementadas dependerá del contexto del incidente, su organización de atención médica y los recursos disponibles. Para ayudar a guiar al equipo de HFRCA a averiguar qué causas raíz y factores contribuyentes abordan, se incluyen algunos consejos a continuación.

Sección 10.6.6.1 Utilizar la Jerarquía de Efectividad para Desarrollar Estrategias Focalizadas en el Sistema

Concéntrese en estrategias de mitigación a nivel de sistema en lugar de soluciones centradas en la persona. Utilice la Jerarquía de Eficacia (Sección 3.5) para determinar si una solución propuesta está centrada en el sistema. Las soluciones centradas en la persona no darán lugar a mejoras en el sistema y, cuando se implementen soluciones centradas en la persona sin abordar los problemas del sistema, es probable que vuelva a ocurrir el mismo incidente o similar.

Sección 10.6.6.2 Calidad sobre la cantidad

En lugar de tratar de implementar muchas estrategias de mitigación de impacto bajo, traten de implementar unas pocas recomendaciones bien pensadas que apuntan al cambio del sistema. Una estrategia de mitigación bien planificada y cuidadosamente ejecutada que apunte a la mejora del sistema será una solución más robusta y a largo plazo para evitar que vuelvan a ocurrir incidentes similares.

Sección 10.6.6.3 Usar el marco SMART

Al redactar las recomendaciones, asegúrese de que son SMART [58] (Tabla 20):

170

Tabla 20. Marco SMART [58] [101]

Como parte del marco SMART, intente asegurar que cualquier estrategia de mitigación primaria caiga dentro del ámbito de control de la organización de la salud, en lugar de un grupo externo, tal como un fabricante o un proveedor. Aunque puede ser necesario trabajar en estrecha colaboración con un fabricante para implementar una estrategia de mitigación, las soluciones que se originan fuera de la organización de la salud, naturalmente serán mucho más difícil de avanzar y controlar. Cuando es necesario implementar una solución que se origina fuera de la organización sanitaria, trabajando estrechamente con los reguladores, los responsables de la formulación de políticas y otras organizaciones sanitarias que enfrentan desafíos similares, puede ayudar a mantener el impulso para que un cambio se realice.

Sección 10.6.6.4 Validar estrategias potenciales de mitigación

Antes de implementar una estrategia de mitigación, debe ser validada para asegurar que tendrá el efecto deseado sin introducir otras consecuencias no deseadas en el sistema. La recopilación de evidencia de la literatura, experiencias de otras organizaciones de salud y recomendaciones de organizaciones profesionales y de seguridad puede ser un ejercicio útil para obtener una comprensión básica de las implicaciones potenciales. Cuando hay poca evidencia o hay rasgos o factores que hacen que su institución de salud sea única, aplicando métodos de factores humanos como observaciones (Capítulo 4), entrevistas, grupos focales y encuestas (Capítulo 5), heurística (Capítulo 7), pruebas de usabilidad Capítulo 8), o un HFFMEA (Capítulo 9).

El Marco de Análisis de Incidentes de Canadá brinda plantillas tanto para evaluar posibles estrategias de mitigación, teniendo en cuenta estas consideraciones (Tabla 21), como para seguir el progreso durante la implementación de estrategias de mitigación (Tabla 22). El individuo responsable de implementar cada estrategia que es acordado por el equipo de HFRCA debe juntar un plan que describe un plan de proyecto, plazos, recursos requeridos y medidas de éxito. El individuo o equipo que implementa cada estrategia de mitigación no tiene que ser el mismo que el equipo de HFRCA; sin embargo, dependiendo del incidente y la estrategia de mitigación, puede ser útil mantener al equipo del HFRCA involucrado como un grupo asesor para mantener cierta consistencia y supervisión.

Objetivo específico Una cuestión claramente definida con un alcance conocido

Medible Demostrar un impacto en los resultados a través de un indicador o medidor de progreso

Alcanzable Se puede lograr teniendo en cuenta los recursos disponibles

Resultados realistas son posibles dado los recursos disponibles

Alcanzable oportunamente en el marco de tiempo de implementación definido

171

Tabla21. Lista de prioridades de las acciones de la RCA [99]

Acción recomendada (categoría)

Riesgo (evaluación de la gravedad)

Jerarquía de Eficacia (alto, medio, bajo apalancamiento)

Predictores de Éxito (alineación, mecanismos existentes, ganancias rápidas)

Nivel del sistema objetivo

Evidencia

¿Disponible?

Qué

¿Tipo?

Confirmar Validez, Factibilidad

Orden de prioridad o calendario

Tabla 22. Seguimiento de las acciones de una RCA [99]

#

Recomendación Fuente e ID #

Fecha Progreso registrado

Calendario (Fecha de

finalización)

Área Objetivo

Nivel de Riesgo

Responsable Individual

Sección 10.7. Qué hacer con un HFRCA completado

Sección 10.7.1. Crear un borrador de informe

Una vez que se haya completado el HFRCA y se haya tomado una decisión sobre las estrategias de mitigación con las que la organización sanitaria avanzará, se debe crear un informe que resume el incidente y el proceso HFRCA. Elimine la mayor cantidad de información de identificación sobre el paciente y el personal involucrado en el incidente como sea posible con fines de privacidad.

Una vez redactado, el informe debe ser etiquetado como "Borrador" y "Confidencial" y luego compartido con los principales interesados para su revisión. La preparación de un informe después de un incidente que incluya información sobre la recolección de información, la documentación, el análisis y el proceso de desarrollo de la estrategia de mitigación puede contribuir al aprendizaje organizacional y la memoria cuando ocurre otro evento centinela. Cuando se comparte con el personal, este tipo de informe puede proporcionar un contexto útil para que los responsables y afectados por las estrategias de mitigación entiendan la razón de ser que impulsa cualquier cambio.

Considere compartir información des-identificada sobre el incidente, el análisis y las estrategias de mitigación planeadas, más allá de su institución de salud, si la alta gerencia apoya este tipo de divulgación. Si se admite esta forma de compartir, puede ser una oportunidad invaluable para que otras organizaciones aprendan del incidente para que eventos similares puedan evitarse en otras instituciones.

172

Sección 10.7.2. Conducir un HFFMEA

Dependiendo del contexto del incidente y los hallazgos del HFRCA, el equipo HFRCA puede desear considerar la realización de un HFFMEA para identificar factores de riesgo inmediatamente implicados en el evento centinela, pero que podrían contribuir a un incidente futuro. Consulte el Capítulo 12 para obtener información sobre cómo realizar un HFFMEA.

Sección 10.8. Limitaciones de HFRCA

Aunque HFRCA puede ser un excelente medio para entender las causas raíz que contribuyeron a un evento centinela, también hay algunos desafíos y limitaciones a considerar.

Sección 10.8.1. Los Recursos Requeridos

La realización adecuada de un HFRCA es un recurso intensivo, ya que puede ser un tiempo para un equipo multidisciplinario para identificar las causas raíz de un evento centinela. Para que un HFRCA tenga impacto, el equipo multidisciplinar también tendrá que dedicar tiempo a identificar e implementar estrategias de mitigación para abordar las causas raíz identificadas. Aunque HFRCA puede ser un recurso intensivo, los beneficios de completar con éxito este tipo de análisis son sustanciales. La prevención de futuros pacientes de ser perjudicados como resultado de un evento similar es una oportunidad invaluable.

Sección 10.8.2. HFRCA no es apropiado para cada incidente

Dado que el HFRCA tiene la intención de identificar las causas raíz del sistema y los factores contribuyentes, los incidentes en los que una persona causa intencionalmente daño no son apropiados para el análisis usando HFRCA. Ejemplos de tales circunstancias incluyen actos criminales, actos intencionalmente inseguros, abuso de sustancias por parte del personal y abuso de pacientes de cualquier tipo. Para determinar si un incidente cae en la categoría de daño no deseado causado por factores del sistema o daño intencional, se recomienda el uso del Árbol de decisión de incidentes (Figura 26).

Sección 10.8.3. Completar un HFRCA requiere tacto

Después de un evento centinela, es normal que el personal involucrado en el incidente esté molesto y asustado acerca de posibles acciones punitivas hacia ellos, o hacia sus colegas, sobre todo si este enfoque fue utilizado históricamente. En consecuencia, es de suma importancia que los que llevan a cabo la investigación sean sensibles y reconozcan que cualquier interacción debe dejar al personal sentirse apoyado, en lugar de perpetuar cualquier sentimiento de miedo o paranoia. Siga la guía proporcionada para realizar observaciones (Capítulo 4) y entrevistas (Capítulo 5) para que el personal no se sienta auditado o juzgado, sino que esté allí para aprender de ellos para que el sistema alrededor de ellos sea más seguro.

173

Sección 10.9. Recursos adicionales

Informes

1. Incident Analysis Collaborating Parties. Canadian Incident Analysis Framework.

Edmonton, AB: Canadian Patient Safety Institute; 2012. Incident Analysis

Collaborating Parties are Canadian Patient Safety Institute (CPSI), Institute for Safe

Medication Practices Canada, Saskatchewan Health, Patients for Patient

SafetyCanada (a patient-led program of CPSI), Paula Beard, Carolyn E. Hoffman

andMicheline Ste-Marie. Available at www.patientsafetyinstitute.ca

Herramientas y marcos disponibles en línea

1. Veterans Affairs National Centre for Patient Safety Root Cause Analysis Tools

http://www.patientsafety.va.gov/CogAids/RCA/index.html#page-4

2. Veterans Affairs National Centre for Patient Safety Root Cause Analysis Triage

and Triggering Questions

http://www.patientsafety.va.gov/CogAids/Triage/index.html

3. The Joint Commission Framework for Conducting a Root Cause Analysis and

Action Plan

http://www.jointcommission.org/Framework_for_Conducting_a_Root_Cause_An

alysis_and_Action_Plan/

4. National Health Services (UK) Root Cause Analysis Toolkit

http://www.nrls.npsa.nhs.uk/resources/rca-conditions/

Ejemplos de análisis de causa raíz

1. ISMP Canada published RCA’s:

• Fluorouracil Incident Root Cause Analysis http://www.ismp-

canada.org/download/reports/FluorouracilIncidentMay2007.pdf

• Hydromorphone/Morphine Event

http://www.ismp_canada.org/download/HydromorphoneMorphine_RCA_Report_final12.pdf

• The Joint Commission - Sentinel Event Data: Root Causes by Event Type

http://www.jointcommission.org/sentinel_event.aspx

• The Joint Commission - Sentinel Event Data: Root Causes by Event Type

174

Compras Informadas Factores Humanos

175

Capítulo 11. Factores Humanos: adquisiciones informadas y Proceso de implementación

Sección 11.1. Preparando el escenario

Desafortunadamente, la poca consideración de los factores humanos en el diseño y la selección de la tecnología es tan frecuente en la asistencia sanitaria que la mayoría de los profesionales de la tecnología biomédica pueden recordar fácilmente incidentes de seguridad de los pacientes que implican errores de uso de la tecnología. Los incidentes que involucran quemaduras electroquirúrgicas inadvertidas [59, 60], electrocución [61, 62], y conexiones erróneas entre diferentes tipos de mangueras, tales como mangueras epidurales e IntraVenosas, son todos ejemplos de errores de uso que pueden prevenirse incorporando principios de factores humanos en el diseño y selección de la tecnología médica [63-66].

Aunque un proceso típico de adquisición normalmente resulta en la selección e implantación de una tecnología que satisface las necesidades y deseos de la organización hospitalaria, no conducirá intrínsecamente a un producto que satisfaga las necesidades y deseos de los usuarios finales. Esto es problemático por varias razones; No sólo el usuario final se quedará atascado utilizando la tecnología durante un número de años, tambienla seguridad del paciente puede verse comprometida cuando una tecnología no apoya a los usuarios en el contexto de su trabajo. No basta con seleccionar simplemente una tecnología que funcione de acuerdo con especificaciones definidas, porque tener una tecnología que es técnicamente robusta no necesariamente se traduce en un producto que funcionará bien en el entorno de trabajo real. Un dispositivo que es técnicamente robusto puede llegar a ser bastante débil cuando se trata de usabilidad, especialmente si los factores humanos no se han incorporado en el diseño del dispositivo, o si el dispositivo encaja mal con los usuarios y entornos de uso previstos.

Mediante la incorporación de factores humanos en un proceso de adquisición más tradicional, una organización sanitaria no sólo tiene el potencial de seleccionar un producto que: 1) cumpla con las especificaciones técnicas; 2) cumpla con los requisitos clínicos; 3) cumpla con las restricciones presupuestales, y 4)viene de un proveedor de renombre que puede proporcionar mantenimiento sostenido y soporte de formación en el tiempo, sino también un producto que se ajuste y apoyar al usuario, dado el contexto de uso. Esto es importante porque es cuando hay áreas de desajuste entre una tecnología y las necesidades de los usuarios que los incidentes son más probables de ocurrir.

Afortunadamente, gracias en parte a los esfuerzos de la Administración de Alimentos y Medicamentos de los Estados Unidos (FDA), los factores humanos se están convirtiendo cada vez más en un requisito estándar del proceso de diseño de tecnología médica, particularmente para el diseño de bombas de infusión (67). Un estudio de Johnson et al. [68] destacó varios desafíos comunes experimentados durante la adquisición de dispositivos de infusión, entre ellos: (1) en forma rutinaria, los usuarios de primera línea no contribuyen a la decisión de compra final, (2) se consideran muy pocos productos para la compra, (3) hay

176

falta de retroalimentación sistemática por parte de los usuarios clínicos, lo que resulta en falta de foco y rigurosidad en relación con aspectos de seguridad, (4) las evaluaciones se limitan a la consideración de las especificaciones técnicas, (5) el costo tiende a orientar las decisiones tempranamente en el proceso, y (6) la decisión final se toma sobre la base de las implicaciones de los factores mencionados, más que sobre consideraciones de usabilidad y seguridad. El proceso de adquisiciones y ejecución informado por los factores humanos (HFPIP, por sus siglas en inglés) presentado en este capítulo pretende abordar muchos de estos retos para mejorar el proceso tradicional de adquisiciones.

Al elevar el perfil de los factores humanos durante el proceso de adquisición, los profesionales de la tecnología biomédica tienen el potencial de impactar directamente la seguridad del paciente y servir como defensores de los usuarios finales.

Sección 11.2. ¿Qué es HFPIP?

El proceso de adquisición e implementación informada por los factores humanos (HFPIP) es un marco que se puede seguir para apoyar la selección informada por factores humanos de las tecnologías médicas en las organizaciones hospitalarias. Este marco se basa en el proceso tradicional de adquisición mediante la incorporación de métodos y normas de factores humanos para ayudar a informar una decisión y mitigar proactivamente el riesgo residual según se identifica mediante evaluaciones de factores humanos. Este marco se desarrolló de forma iterativa basada en la experiencia adquirida durante varias actividades de adquisición hospitalaria (por ejemplo, [69]).

Sección 11.3. ¿Por qué utilizar HFPIP?

El proceso de adquisición es una excelente oportunidad para hacer una diferencia en la seguridad de los pacientes al asegurar que las tecnologías seleccionadas, que habitualmente permanecen en uso durante varios años, encajan bien con las personas que las utilizarán. Aunque se han hecho progresos en el reconocimiento de la importancia de los factores humanos durante el diseño de dispositivos por parte de los fabricantes, las normas sobre cuándo y cómo incorporar los factores humanos en las tecnologías médicas y los sistemas de información aún no están bien establecidas ni son necesarias para todas las tecnologías. Además, incluso cuando una tecnología médica tiene una interfaz de usuario robusta y bien diseñada, el propio dispositivo puede no ser un buen ajuste para los usuarios particulares o el entorno de uso. En consecuencia, se recomienda encarecidamente que las organizaciones sanitarias incorporen factores humanos en sus propios procesos de adquisición utilizando el marco HFPIP.

La aplicación de métodos de factores humanos durante el proceso de adquisición no sólo tiene el potencial de mejorar la seguridad del paciente, sino que también puede aumentar la satisfacción del personal y la aceptación de una nueva tecnología, disminuir la cantidad de capacitación requerida y reducir los costos financieros asociados con litigios y obsolescencia. [68-72]. Finalmente, los métodos de factores humanos presentados como

177

parte del HFPIP pueden ser usados para identificar estrategias de mitigación que aborden áreas de riesgo residual asociadas con la implementación de una tecnología.

Desde la perspectiva del profesional de la tecnología biomédica, utilizando el marco HFPIP durante el proceso de adquisición será útil para:

Seleccionar una tecnología que: Cumple con las especificaciones técnicas y los

requisitos clínicos, cumple con las restricciones presupuestarias, proviene de un

proveedor de buena reputación y satisface las necesidades de los usuarios

teniendo en cuenta el contexto de uso

Desarrollar proactivamente estrategias de mitigación para abordar el riesgo

residual antes de que la tecnología se implemente

Sección 11.4. Cuándo utilizar HFPIP

El marco HFPIP debe usarse siempre que una organización de salud esté planeando adquirir una tecnología que cumpla uno o más de los siguientes criterios:

Se considera que la tecnología es de alto riesgo

Se considera que la tecnología es de alto uso (es decir, se usa frecuentemente por

una o más áreas clínicas)

La tecnología tiene un historial de problemas de seguridad (internos o externos a

la organización)

La tecnología requerirá una gran inversión de capital

La tecnología es omnipresente en toda la organización (ya sea utilizada en muchas

áreas o tiempos para diferentes aplicaciones)

La tecnología es inherentemente complicada

En cualquiera de estos casos, la organización sanitaria puede beneficiarse enormemente del uso del marco HFPIP para incorporar métodos de factores humanos como parte del proceso de adquisición.

Sección 11.5. Preparativos para HFPIP

En preparación para un HFPIP, el profesional de la tecnología biomédica debe entender por qué un proceso de adquisición está siendo llevado a cabo por la institución de salud (por ejemplo, para reemplazar un dispositivo existente, para satisfacer una necesidad que no se está abordando actualmente) y qué tipo de dispositivo es (por ejemplo, bomba de infusión, monitor fisiológico).

178

Sección 11.6. Completar un HFPIP

El marco de HFPIP se describe en la Figura 34. Cada paso será descrito y descrito en esta sección.

Figura 34. El Proceso de Adquisición y Aplicación de Factores Humanos (HFPIP)

La capacidad de cada organización de seguir el HFPIP variará dependiendo de las reglas y regulaciones específicas de la jurisdicción relacionadas con la adquisición. Algunas jurisdicciones, debido a criterios muy rígidos para comprometerse con los proveedores, no apoyarán la inclusión de la investigación de factores humanos y los métodos en el proceso de toma de decisiones. Se recomienda incluir tanto como sea posible la evaluación de los factores humanos, siempre que sea posible, a lo largo del proceso, de modo que, incluso si los resultados de las evaluaciones de factores humanos no se utilizan en el proceso de toma de decisiones, pueden utilizarse para apoyar los esfuerzos de implementación y capacitación.

Sección 11.6.1. Planificación

Sección 11.6.1.1 Crear equipo

El primer paso al realizar un HFPIP es reunir un equipo multidisciplinar que represente a todas las partes interesadas que se ven afectadas por la decisión de adquisición. Considere la posibilidad de incluir a los siguientes miembros del equipo:

• Profesionales de la tecnología biomédica

• Un representante del Departamento de Compras

• Un representante de los factores humanos. Esto podría ser un experto en factores humanos (ya sea interno o externo a la organización), o un profesional de tecnología

179

biomédica dispuesto a conducir evaluaciones de factores humanos basadas en los métodos descritos en este manual.

• Personal de primera línea

• Educadores y líderes clínicos

• Un representante de tecnología de la información y sistemas de información. Para tecnologías consideradas como un sistema de información, o tecnologías que interactúan con un sistema de información.

• Un representante de la planificación de las instalaciones. Para las tecnologías que requieren, son influenciadas por, o parte de un proyecto que implica cambios en la instalación (por ejemplo, la construcción de una nueva unidad).

• Un representante de los almacenes centrales para tecnologías que requieren almacenamiento en una ubicación central o acceso a desechables almacenados.

• Un representante del procesamiento central para tecnologías que requieren esterilización o que tienen requerimientos especiales de limpieza.

• Personal de limpieza para las tecnologías que tendrán que ser limpiadas por el personal de limpieza.

• Alguien de Jurídica, responsable del riesgo y / o un representante de seguridad del paciente. Proporcionar conocimientos históricos sobre los incidentes pasados y el conocimiento del impacto potencial de los eventos adversos relacionados con la tecnología que se está evaluando.

• Un ejecutivo del hospital u otro líder senior para proporcionar una perspectiva organizativa amplia, facilitar el acceso a los recursos requeridos y ayudar a lograr la aceptación relacionada con la gestión del cambio, los procesos de implementación, los cambios en las políticas y los requisitos de capacitación.

Sección 11.6.1.2 Establecer necesidades y deseos

El siguiente paso al conducir un HFPIP es establecer los requisitos que un dispositivo debe cumplir para que sea considerado por la organización. Este es uno de los pasos más importantes del proceso de adquisición, ya que proporciona la base para asegurar que el dispositivo seleccionado cumpla con los requisitos técnicos, clínicos y de usabilidad de la organización y los usuarios finales después de la implementación. En un HFPIP, el establecimiento de estos requisitos depende en gran medida del uso de varios métodos de factores humanos incluyendo observaciones (Capítulo 4), entrevistas, encuestas y grupos focales (Capítulo 5), análisis de tareas (Capítulo 6) y cualquier hallazgo anterior de HFFMEA (Capítulo 9) y / o HFRCA (Capítulo 10).

Será necesario establecer las necesidades y deseos de cada grupo de usuarios que interactuarán con el dispositivo, no sólo en su uso diario en servicio, sino también en el mantenimiento, la limpieza y el almacenamiento durante todo el ciclo de vida de la tecnología. Para ello, primero se debe definir cada tipo de usuario final. Un usuario final puede ser considerado cualquier categoría de usuario que es probable que interactúe con la

180

tecnología a lo largo de todo el ciclo de vida de la tecnología. Es extremadamente importante que cada grupo de usuarios sea incluido, de lo contrario las necesidades y deseos de ese grupo de usuarios no serán incorporados en el proceso de adquisición.

Una vez que cada tipo de usuario final ha sido definido, las necesidades y deseos de cada uno de esos grupos tendrá que ser establecido. Para evaluar los requisitos de los usuarios, se deben responder las siguientes preguntas:

¿Qué tareas debe apoyar la tecnología?

Si una tecnología similar ya está en uso en la organización sanitaria, entonces

o ¿Qué características específicas, configuraciones, informes y otros elementos

personalizables se están utilizando actualmente?

o ¿Qué características no se utilizan, y por qué?

o ¿Qué quisieran hacer usuarios con la tecnología que no es posible

actualmente?

o ¿Puede haber algún incidente pasado o faltas cercanas en la organización

sanitaria que se puedan revisar?

¿Existen incidentes relacionados con la tecnología que se pueden encontrar en bases

de datos de informes de incidentes públicos (por ejemplo, FDA MAUDE)

¿Existen problemas relacionados con la tecnología que han sido reportados por

organizaciones de seguridad (por ejemplo, el Instituto ECRI, ISMP), organizaciones de

estándares (por ejemplo, AAMI) o reguladores (por ejemplo, la FDA)? Un excelente

ejemplo de problemas reportados relacionados con las bombas de infusión se puede

encontrar en el sitio web de la FDA.

Para determinar las tareas que debe soportar una tecnología, es muy recomendable realizar observaciones (Capítulo 4). Esas tareas pueden documentarse mediante el Análisis de tareas (Capítulo 6). Determinar qué características específicas se utilizan y no se utilizan en una tecnología similar, y si hay otras cosas que los usuarios quisieran que una tecnología similar hiciera, se pueden recoger mediante una combinación de observaciones (Capítulo 4) y entrevistas, grupos focales y encuestas (Capítulo 5 ). Como se señaló en el capítulo 4, los datos de observación son complementarios a los datos recopilados utilizando otras técnicas de recolección de datos cualitativos, por lo que se deben realizar observaciones siempre que se hayan realizado entrevistas, grupos focales o encuestas.

Para reunir la información restante sobre los requisitos de los usuarios, debe revisarse la búsqueda de bases de datos internas y públicas de informes de incidentes y la información de organizaciones de seguridad, organizaciones de normalización y reguladores relacionados con la tecnología que se adquiere.

Una vez que las necesidades y deseos del usuario se hayan establecido, se traducirán en requisitos funcionales para la Solicitud de Propuesta (RFP), y se utilizarán posteriormente para ayudar a apoyar la fase de implementación.

181

Sección 11.6.1.3 Escribir y distribuir RFP

Además de los elementos estándar de RFP, como términos legales, acuerdos contractuales, criterios de evaluación y requisitos técnicos del producto, tres características adicionales aumentan la RFP para un HFPIP:

1. Requisitos funcionales (es decir, lo que la tecnología debe ser capaz de hacer)

sobre la base de las necesidades y deseos del usuario

2. Una solicitud de información sobre cómo la tecnología cumple con los estándares

de factores humanos

3. Un resumen del proceso de evaluación de los factores humanos que la tecnología

sufrirá

Requisitos funcionales basados en las necesidades y deseos de los usuarios

El establecimiento de los requisitos de los usuarios se describe en la Sección 11.6.1.2. Una vez establecidos, los requisitos del usuario deben traducirse en requisitos funcionales en la RFP. Por ejemplo, los usuarios de una bomba de infusión pueden expresar la necesidad de poder configurar la bomba y no iniciarla inmediatamente, sin que la bomba genere una alarma porque está inactiva. La RFP podría especificar esto como un requisito funcional diciendo "La bomba debe proporcionar un medio de retrasar el inicio de una infusión, sin alarmar".

Solicitud de información sobre cómo la tecnología cumple con los estándares de factores humanos

Documentación que ilustra cómo un diseño y características tecnológicas cumplen con las secciones pertinentes de la norma de factores humanos ANSI / AAMI HE75: 2009 Ingeniería de factores humanos - El diseño de dispositivos médicos [73] debe solicitarse a cada proveedor. Dado que esta norma es bastante detallada y bastante larga, todas las secciones pertinentes de la norma para la tecnología que se está considerando deben ser especificadas como parte de la RFP. Como alternativa a la especificación de esta información, se podría pedir a los proveedores que describieran cómo se usó el estándar ANSI / AAMI HE75 para diseñar la tecnología en cuestión.

Hay otros estándares de los factores humanos de la tecnología médica, algunos de ellos son más pertinentes a tipos específicos de tecnología. La Tabla 23 proporciona una lista de estándares de factores humanos de los dispositivos médicos compilados que fue presentada en el Simposio de Salud de la Sociedad de Factores Humanos y Ergonomía 2012 [74].

182

Tabla 23. Estándares de factores humanos de dispositivos médicos

Título Estándar Propósito

ANSI / AAMI HE75: 2009

Ingeniería de factores humanos - Diseño de dispositivos médicos

Proporcionar un documento único y completo para la orientación de factores humanos relacionados con el diseño de dispositivos médicos.

IEC 60601-1: 2005

ANSI / AAMI ES60601-1: 2011, 3ª ed.

Norma general de seguridad y rendimiento esencial para equipos eléctricos médicos

Introducción a las subpartes estándar con una variedad de dispositivos médicos eléctricos

IEC 60601-1-8: 2006 Garantía de la IEC 60601-1: 2005 sobre requisitos generales, ensayos y guías para sistemas de alarma.

Recomienda parámetros de diseño de alarma visual y auditiva, p. color,

Frecuencia y cadencia.

IEC TR 60878: 2003 Símbolos gráficos para equipos eléctricos en la práctica médica

Recoge los símbolos existentes aplicables a los dispositivos médicos y los presenta en 15 categorías de dispositivos médicos

ISO 15223-1: 2012

ISO 15223-2: 2010

Dispositivos médicos - Símbolos que se utilizarán con las etiquetas de los dispositivos médicos, el etiquetado y la información que se suministrará

Parte 1 - Identifica los requisitos para los símbolos utilizados en el etiquetado de los dispositivos médicos que transmiten información sobre el uso seguro y eficaz de dispositivos médicos Parte 2 - Desarrollo de símbolos, selección y validación

ISO 14971: 2007 Dispositivos médicos - Aplicación de la gestión del riesgo a los dispositivos médicos

La norma definitiva sobre los principios de la gestión del riesgo, p. FTA, FMEA a dispositivos médicos

IEC 60601-1-11: 2011 Estándar colateral: Requisitos para el equipo eléctrico médico y los sistemas eléctricos médicos

Describe los requisitos particulares para los dispositivos médicos del cuidado médico casero

183

usados en el ambiente del cuidado médico del hogar

ISO 80369 - 1: 2010 Conectores de pequeño calibre para líquidos y gases en aplicaciones sanitarias - Parte 1: Generalidades Requisitos Partes 2 a 7 para dispositivos particulares

Describe los conectores estándar que son utilizables e imposibles de desconectar a través de categorías de dispositivos médicos

IECEE - TRF's TRF - Formularios de

informes de pruebas

Utilizados por los organismos notificados en la UE y en otras partes para medir el cumplimiento de las normas IEC / ISO

El propósito de solicitar y recopilar esta información es doble: En primer lugar,

proporciona una indicación de si la tecnología es probable que sea robusta en términos de diseño de interfaz de usuario. En segundo lugar, actúa como una señal a los vendedores de que los factores humanos son una consideración importante al tomar decisiones de adquisición, y por lo tanto, debe ser abordado por los vendedores durante el desarrollo del producto.

Desccripción de procesos de evaluación de factores humanos aplicables a la tecnología

Se debe incluir una descripción de las evaluaciones de factores humanos que se llevarán a cabo durante la fase de evaluación del proceso de compra, como parte de la RFP HFPIP. Ejemplos de evaluaciones de factores humanos que podrían aplicarse incluyen un análisis heurístico (Capítulo 7) y/o pruebas de usabilidad (Capítulo 8). Para las pruebas de usabilidad, es importante que los vendedores entiendan que no estarán presentes durante esas evaluaciones, pero que se espera que proporcionen lo siguiente:

Un número específico de dispositivos y desechables

Personalización de la configuración del producto para apoyar la evaluación

Capacitación para el especialista en tecnología biomédica o especialista en

factores humanos

La mayoría de los procesos de compra requerirán que la RFP especifique los criterios detallados de evaluación. Esto incluirá especificar las métricas asociadas con las evaluaciones de factores humanos. Esto es desafiante porque los resultados de las pruebas de factores humanos son primordialmente cualitativos. Una manera de abordar esto es asignar puntos o ponderar cada etapa del proceso de evaluación e incluir la evaluación de los factores humanos como una de las etapas (por ejemplo: costo=30%, capacidad de cumplir con las especificaciones=30%, factores humanos/evaluación clínica=40%). Para determinar el número de puntos que cada producto recibe para los factores humanos/evaluación clínica,

184

los puntos de evaluación deben asignarse a categorías que correspondan a varios aspectos de la evaluación, por ejemplo:

Problemas de usabilidad: comparación o problemas críticos, graves y moderados

Eficiencia de tareas: comparación de tiempo para completar tareas frecuentes y

críticas en el tiempo

Cuestionarios posteriores a la prueba: comparación de la retroalimentación

directa del usuario y las preferencias de cada bomba

La puntuación de riesgos, similar a la desarrollada para un HFFMEA, debe ser desarrollada para asignar valores cuantitativos a los problemas de usabilidad identificados.

Una vez que el RFP ha sido escrito y distribuido, y las propuestas han sido recibidas por la organización de salud, las tecnologías que cumplan con los requisitos establecidos en el RFP deben ser identificados y seleccionados.

Sección 11.6.2. Evaluación

El marco de HFPIP complementa una evaluación típica de tecnología para compra, e introduce métodos de factores humanos para evaluar el desempeño clínico de la tecnología. Estos métodos de factores humanos incluyen análisis heurístico (Capítulo 7), pruebas de usabilidad (Capítulo 8) y HFFMEA (Capítulo 9).

Sección 11.6.2.1 Análisis heurístico

Cuando se aplica durante un proceso de adquisición, se debe realizar un análisis heurístico (Capítulo 7) antes de la prueba de usabilidad o HFFMEA porque se puede hacer rápidamente y no requiere la participación de personas fuera del equipo de adquisiciones. Además, los resultados de un análisis heurístico pueden a veces proporcionar evidencia suficiente para apoyar la eliminación de uno o más productos porque puede destacar que el producto no cumple con los requisitos funcionales o criterios de usabilidad descritos en la RFP. Tenga en cuenta que este resultado es raro porque las violaciones identificadas en el análisis heurístico deben demostrar claramente las violaciones de los requisitos funcionales esbozadas en la RFP.

Lo ideal sería que el especialista en factores humanos y otros dos a cuatro miembros del equipo que estén capacitados para realizar análisis heurísticos, revisen cada tecnología. Es preferible tener por lo menos un evaluador que es un experto doble - alguien que es a la vez experto en la materia (es decir, usuario) y entrenado en la realización de análisis heurísticos. Cada persona que realice un análisis heurístico debe hacerlo de manera aislada para no sesgar los hallazgos, a menos que los especialistas en factores humanos no estén familiarizados con la tecnología o contexto de uso. En este caso, el especialista en factores humanos debe emparejarse con un experto en la materia para hacer el análisis.

Una vez que cada evaluador ha completado el análisis heurístico y documentado sus hallazgos, el especialista en factores humanos debe compilar los resultados y resumirlos para todo el equipo de adquisiciones. El resumen debe incluir descripciones detalladas del impacto potencial para el personal y / o la seguridad del paciente para cada una de las violaciones heurísticas. El propósito de compartir los resultados del análisis heurístico es

185

alertar al equipo sobre posibles problemas y consecuencias de cada problema derivados de una violación heurística. El equipo puede querer calificar cada infracción heurística utilizando una escala de gravedad. Cualquier problema que tenga impactos potenciales para la seguridad del paciente debe resaltarse para que las tareas asociadas con estos problemas puedan ser incluidas en los escenarios de pruebas de usabilidad, que son necesarias porque las violaciones heurísticas no siempre resultan en problemas de usabilidad cuando se usan en el contexto. Las pruebas de usabilidad, sin embargo, están dirigidas a identificar los problemas en su contexto.

Sección 11.6.2.2 Pruebas de usabilidad

Cuando se aplica durante un proceso de adquisición, las pruebas de usabilidad (Capítulo 8) deben realizarse después de un análisis heurístico. Los escenarios de prueba de usabilidad deben incorporar cualquier aprendizaje del análisis heurístico para que cualquier problema potencial derivado de violaciones pueda ser probado en la práctica. Se recomienda realizar pruebas de usabilidad además de un análisis heurístico, ya que tiende a ser una evaluación mucho más completa que permite considerar el rendimiento del usuario en el contexto del entorno de uso. Cuando los problemas se identifican a través de un análisis heurístico, la manifestación de estos problemas, su impacto en la seguridad del paciente y sus causas raíz pueden sólo ser evidentes cuando la tecnología se coloca en un entorno representativo con usuarios finales reales.

Cuando se realizan pruebas de usabilidad para apoyar la adquisición, se debe pedir a los participantes que piensen en voz alta (Sección 8.5.8) para que los que recopilen datos puedan llegar más fácilmente a las causas raíz de los problemas que surjan.

Las pruebas de usabilidad como parte de un HFPIP proporcionarán al equipo de adquisiciones una comprensión de los problemas de usabilidad asociados con una tecnología en particular, una comparación de problemas de usabilidad entre los dispositivos que se están considerando, videos que resaltan cómo los problemas de los dispositivos llevan a errores de uso y reacciones de los usuarios mientras interactúan con la tecnología y un guión de capacitación (así como conocimientos sobre posibles áreas de mejora para el guión de capacitación) que pueden utilizarse como base para la formación de los usuarios durante la implementación.

Sección 11.6.2.3 HFFMEA

Cuando se aplica durante un proceso de adquisición, HFFMEA (Capítulo 9) debe realizarse después de pruebas de usabilidad, si los recursos lo permiten. Los resultados del análisis heurístico y las pruebas de usabilidad proporcionan una comprensión bastante completa de los modos de fallo asociados con cada producto. Un HFFMEA puede proporcionar información sobre el riesgo residual que probablemente se asociará con una tecnología después de que se hayan implementado estrategias de mitigación destinadas a solucionar los problemas identificados de forma proactiva.

Sección 11.6.2.4 Ensayos en uso

En algunos casos, una organización de salud puede optar por incluir un ensayo en uso como parte del proceso de adquisición. Un ensayo en uso es un período práctico de

186

evaluación donde la tecnología se utiliza en pacientes en un entorno clínico. De esta manera, se puede determinar la capacidad de una tecnología para satisfacer las necesidades de los usuarios. Si se realiza un ensayo en uso, se pueden realizar observaciones adicionales durante ese proceso. Además, las entrevistas, grupos focales y encuestas también se pueden completar para recopilar las percepciones de los usuarios sobre la tecnología.

Dependiendo de si los ensayos en uso tienen lugar antes o después de las pruebas de usabilidad, pueden confirmar lo que se encontró durante las pruebas de usabilidad o ayudar a informar los escenarios que se utilizarán para las pruebas posteriores. Para obtener información de la más alta calidad de los ensayos en uso, trate de minimizar la cantidad de interacción y resolución de problemas que los vendedores hacen con la tecnología mientras está en uso, a favor de que los usuarios lo hagan sin ayuda, siempre y cuando el producto esté siendo utilizado de forma segura. Demasiada participación de los vendedores puede enmascarar defectos de diseño en la tecnología que afectan su usabilidad. Además, cuando los usuarios tienen dificultades para utilizar una tecnología antes de la implementación, proporcionan una valiosa oportunidad para experimentar y observar problemas y desafíos relacionados con el dispositivo en el contexto del uso. Esto también ayuda a los usuarios a identificar, por ellos mismos, la necesidad de entrenamiento en el dispositivo durante la implementación.

Sección 11.6.2.5 Proporcionar comentarios a los proveedores

La organización de salud puede querer considerar compartir algunos resultados de las evaluaciones de factores humanos con los proveedores para proporcionar retroalimentación importante. Sin embargo, esto debe hacerse con precaución, ya que los requisitos de confidencialidad y las políticas hospitalarias deberán mantenerse. Nunca comparta informes entre diferentes proveedores.

Sección 11.6.3. Implantación

El ajuste entre una tecnología, los usuarios y el entorno de uso es crítico para asegurar que los usuarios acepten, y de forma rutinaria y eficaz usen una tecnología una vez que se ha implementado [75-81]. El Modelo de Aceptación de la Tecnología, un modelo que describe cómo los usuarios llegan a aceptar y utilizar una tecnología, [82, 83] explica que para que los usuarios desarrollen una intención conductual de usar una tecnología, que es un predictor confiable del uso real, deben tener una actitud positiva hacia esa tecnología. Esta actitud positiva se forma sobre la base de la utilidad percibida y la facilidad de uso de la tecnología por el usuario.

La aplicación de métodos de factores humanos a lo largo del proceso HFPIP ayudará a asegurar que existe un ajuste apropiado entre la tecnología y el sistema de trabajo, y resultará en la selección de una tecnología centrada en el usuario. Sin embargo, incluso después de aplicar métodos de factores humanos durante los procesos de planificación y evaluación, todavía hay una serie de tareas necesarias durante la fase de implementación para soportar una transición fácil para los usuarios. Estas tareas incluyen decidir sobre el producto, configurar el producto y planificar e implementar el producto.

187

Sección 11.6.3.1 Decidir sobre el (los) producto (s)

Una vez que se hayan completado las evaluaciones tecnológicas, se debe tomar una decisión sobre la selección final del producto. Para tomar esta decisión, el equipo de adquisiciones tendrá que sopesar varios factores. La clave para el marco de HFPIP es la incorporación de los resultados de los métodos de evaluación de factores humanos que se llevaron a cabo como parte del proceso de adquisición (es decir, análisis heurístico, pruebas de usabilidad y HFFMEA). El equipo de adquisiciones puede encontrar útil resumir los problemas de factores humanos que se encuentran como parte del HFPIP ya sea en categorías a través de las tecnologías consideradas y / o utilizando una matriz de puntuación estilo HFFMEA para evaluar posibles problemas de usabilidad basados en su riesgo relativo.

Si se ha completado una evaluación prospectiva del riesgo como la HFFMEA para la tecnología que se está adquiriendo, cualquier posible estrategia de mitigación que pueda abordar problemas asociados con la tecnología también debe ser incorporada en el proceso de toma de decisiones. Para más detalles véase el Capítulo 9 HFFMEA, y la Sección 3.5 Jerarquía de Eficacia.

Sección 11.6.3.2 Configurar producto (s)

Como se habrá identificado durante la fase de evaluación del HFPIP, la tecnología que se está evaluando puede tener características estándar que pueden ser modificadas o activadas / desactivadas por la organización sanitaria. El modo en que se configuran estas configuraciones puede tener serias implicaciones para la seguridad y la usabilidad, y por lo tanto, cualquier decisión debe hacerse con una cuidadosa consideración y consulta con cada grupo de usuarios. Por ejemplo, si decide configurar los ajustes de alarma, considere la posibilidad de que fallen las alarmas (falsos negativos) o falsas alarmas (falsos positivos). La configuración de alarma elegida debe garantizar que las alarmas se generan sólo cuando el personal necesita ser alertado de una situación que podría suponer un riesgo para el cuidado efectivo del paciente. Los hallazgos de las evaluaciones de factores humanos (es decir, heurísticas, pruebas de usabilidad, HFFMEA) también deben usarse para ayudar a elegir los ajustes de personalización apropiados.

Sección 11.6.3.3 Planificar e implementar productos

Realización de cambios en el sistema de trabajo

Como parte de la planificación requerida antes de la implementación, puede ser necesario hacer cambios en el sistema de trabajo para apoyar la integración de la nueva tecnología en ese sistema. Estos cambios podrían relacionarse con cosas como políticas, flujo de trabajo del personal, sistemas de tecnología de la información, o formularios y listas de verificación, por ejemplo. Las evaluaciones de factores humanos llevadas a cabo como parte del HFPIP proporcionarán una visión de los cambios que son necesarios dado el contexto de la tecnología en particular y el proyecto de implementación.

Entrenamiento y educación

También como parte del proceso de planificación previo a la implementación, será necesario capacitar al personal para que utilice la nueva tecnología. El lector puede recordar

188

en la Sección 3.5, Jerarquía de Eficacia, que la Educación y el Entrenamiento es el tipo menos efectivo de estrategia mitigadora a lo largo de la jerarquía. Esto es cierto cuando el entrenamiento es para enseñar a los usuarios a superar un producto mal diseñado. Por el contrario, cuando se introduce a los usuarios por primera vez en una tecnología, será necesario proporcionar algún nivel de formación para familiarizar a los usuarios con las interfaces tecnológicas y cómo utilizar la tecnología para alcanzar los objetivos clínicos. En el caso del HFPIP, ya que se han utilizado varios métodos de factores humanos para evaluar la tecnología, el equipo de adquisición ya conocerá los aspectos significativos del diseño y se podrán planificar estrategias de mitigación que se dirigen a niveles más altos de la Jerarquía de Eficacia.

La capacitación es una oportunidad para dar forma positiva a las actitudes de los usuarios sobre la utilidad de una tecnología, por lo que es importante estructurar un programa de capacitación para asegurar que el personal obtenga una cantidad adecuada de información en el nivel adecuado de detalle para apoyar sus actividades laborales. El contenido presentado durante el entrenamiento debe cubrir no sólo "saberde los botones" (por ejemplo, qué botón presionar para iniciar una bomba de infusión), sino también los principios subyacentes que gobiernan cómo funciona la tecnología, o por qué un proceso debe hacerse de una manera determinada, la dinámica de fluidos detrás de tener que limpiar una línea de medicación con soluciónnormal salina para entregar el medicamento al paciente). Cuando los usuarios son enseñados por rotación sin una comprensión real de los principios subyacentes de la operación, serán más vulnerables a los errores.

Para desarrollar contenido de capacitación, considere el uso de secuencias de comandos de entrenamiento actualizadas de las pruebas de usabilidad. Otro enfoque sería comenzar con el análisis de tareas para asegurar que los materiales de capacitación aborden y sean específicos de cada tarea para cada tipo de usuario. Esté preparado para probar iterativamente y revisar el diseño de la capacitación antes de implementarlo. Dependiendo del contexto del ejercicio de adquisición, puede ser conveniente evaluar la competencia de los nuevos usuarios con un ejercicio práctico para demostrar su capacidad para realizar cada tarea requerida.

Deje tiempo suficiente para que los usuarios adquieran experiencia práctica durante el entrenamiento. Considere la posibilidad de configurar una simulación, similar a una prueba de usabilidad de baja fidelidad, para que los usuarios puedan obtener una mejor idea de cómo usar la tecnología aún en un entorno seguro (es decir, antes de conectarse con un paciente). Esto proporcionará a los usuarios confianza adicional y es probable que les ayude a retener la información aprendida.

Implantación

Cómo y cuándo una tecnología realmente se implantará dependerá no sólo de la tecnología que se adquirió, sino también en las decisiones internas tomadas por la organización de la salud y el equipo HFPIP. Una vez que la tecnología ha sido implementada, es importante que el personal se sienta apoyado, ya que la transición a una nueva tecnología puede ser muy estresante. Para ayudar a asegurar que el personal se sienta apoyado, considere la posibilidad de tener líderes clínicos altamente capacitados, o profesionales de

189

tecnología biomédica, que estén disponibles en cada unidad afectada y que puedan actuar como un recurso principal para el personal durante la transición.

Apoyo transitorio y continuado

Como con cualquier nueva habilidad, aprender a usar una nueva tecnología puede estar asociada con una curva de aprendizaje con gran pendiente, y puede conducir a la frustración y la ansiedad por parte del usuario. En la asistencia sanitaria, esta ansiedad a menudo se amplifica porque la mayoría de las tecnologías tienen el potencial de dañar a los pacientes y / o al personal cuando se usan incorrectamente. Asegúrese de que el personal tenga la opción de obtener una práctica continua y capacitación especializada sobre la tecnología si no se siente cómodo al usarla después de la sesión de capacitación planeada. Dependiendo del contexto de la implementación de la tecnología, es posible que se requieran pruebas regulares de competencia, en las que se les pedirá a los usuarios que demuestren los usos comunes de la tecnología tal como se enseñan.

Sección 11.7. Qué hacer con las conclusiones de HFPIP

Una vez que el HFPIP ha sido completado y la tecnología implementada, se debe crear un informe que resume el proceso HFPIP. Este tipo de informe puede proporcionar contexto útil y memoria organizativa sobre el proceso de adquisición que se siguió y una justificación para las decisiones tomadas.

Sección 11.8. Limitaciones de HFPIP

Aunque HFPIP puede mejorar la seguridad del paciente y proporcionar una visión durante la adquisición para ayudar en la selección de una tecnología que satisfaga las necesidades técnicas, de usuario y de organización, hay una serie de limitaciones que deben tenerse en cuenta.

Sección 11.8.1. Los Recursos Requeridos

Adquirir una nueva tecnología es una empresa que requiere muchos recursos y la incorporación de métodos de factores humanos en el proceso tal como se describe en el marco de HFPIP puede requerir aún más recursos. Las organizaciones comprometidas con la mejora de la seguridad de los pacientes y deseosas de realizar las otras ganancias que pueden derivarse de la incorporación de factores humanos, deberán proporcionar al profesional de la tecnología biomédica un tiempo dedicado para completar estas actividades.

Sección 11.8.2. HFPIP puede no ser factible para cada dispositivo médico

Debido a los recursos requeridos, no será factible someterse al proceso HFPIP para cada tecnología que se adquiere. Para ayudar a determinar si se debe usar HFPIP, consulte la Sección 11.4 Cuándo usar HFPIP.

Sección 11.8.3. La implementación es Rara vez perfecta

Incluso cuando se utiliza el marco HFPIP y se incorporan métodos de factores humanos a lo largo del proceso de adquisición, es poco probable que la implementación de una nueva tecnología sea perfecta. Dependiendo de la tecnología que se está adquiriendo, habrá una enorme cantidad de complejidad para manejar, y es inevitable que habrá lecciones

190

aprendidas en el camino. Siempre que sea posible, trate de escalonar la implementación "en vivo" de una tecnología para que solo una unidad realice la transición a la vez. De esta forma, cualquier lección aprendida puede ser incorporada para futuras implementaciones de unidades.

Sección 11.8.4. Incluso la tecnología mejor diseñada fallará de vez en cuando

Incluso la tecnología mejor diseñada seguirá fallando de vez en cuando. Por esta razón, es importante que se establezca un plan de contingencia para que los usuarios sepan qué hacer. Asegúrese de que la organización sanitaria tenga un mecanismo de información en su lugar para poder recopilar e interpretar posibles problemas de toda la organización. Los usuarios deben entender la tecnología lo suficientemente bien como para poder improvisar una respuesta (ya sea con la tecnología o con un profesional de la tecnología biomédica) de una manera segura y clínicamente apropiada.

Sección 11.9. Recursos adicionales

Estándares de dispositivos médicos de factores humanos

ANSI/AAMI HE75, 2009 Edition - Human factors engineering— Design of medical

devices. http://www.aami.org/publications/standards/he75.html

Recursos

FDA 2014 Examples of Reported Infusion Pump Problems. Available at: http://www.fda.gov/medicaldevices/productsandmedicalprocedures/gener alhospitaldevicesandsupplies/infusionpumps/ucm202496.htm#3

191

Parte III. Estudios de caso: Aplicación de Factores Humanos a la Gestión de la Tecnología

de la Salud

"Lo que parece un problema de personas a menudo es un problema de situación ... Cuando usted comprende la [Situación], usted hace el cambio más probable ... "

-Chip y Dan Heath, autores de Switch: Cómo cambiar las cosas cuando el cambio es difícil

Los profesionales de la tecnología biomédica ya desempeñan un papel importante en la promoción de la seguridad de los pacientes mediante la integración de las tecnologías sanitarias para que encajen bien con los flujos de trabajo clínicos, los dispositivos existentes y el entorno de uso. La filosofía de los factores humanos está bien alineada con estos objetivos porque los factores humanos se enfocan en mejorar el ajuste o relación entre varios componentes a nivel de sistema y algunos lectores pueden realmente encontrar que han estado usando métodos de factores humanos sin darse cuenta que son considerados como tales.

La tercera parte de este libro pretende conectar los métodos de factores humanos descritos en la Parte II a las tareas de un profesional de la tecnología biomédica. Se compone de dos estudios de caso que ilustran cómo los métodos de factores humanos pueden ser incorporados en tareas típicas de la tecnología biomédica profesional. El Capítulo 12 presenta un estudio de caso para mostrar cómo los factores humanos pueden ser incorporados en el proceso de adquisición y el Capítulo 13 utiliza un segundo estudio de caso para resaltar las oportunidades de aplicar métodos de factores humanos durante el análisis de incidentes.

Reconocemos que algunos profesionales de la tecnología biomédica pueden no tener la autoridad organizativa para llevar a cabo análisis de factores humanos. Es nuestra intención apoyar a estos profesionales proporcionando ejemplos que les ayudarán a delinear proyectos de factores humanos (incluyendo métodos, recursos y plazos) y describir los beneficios esperados para que puedan inscribir al liderazgo senior en la expansión de su rol para incluir factores humanos Análisis.

192

Capítulo 12. Estudio de Caso de Soporte de Adquisiciones

Los profesionales de la tecnología biomédica están a menudo involucrados cuando una organización sanitaria decide adquirir una nueva tecnología médica. Como tal, los profesionales técnicos en estas funciones están bien posicionados para aplicar los métodos de factores humanos a lo largo del proceso de adquisición para garantizar que cualquier tecnología elegida por la organización de salud encaja bien con las personas que lo utilizarán dado el contexto de uso.

Para ilustrar cómo los profesionales de la tecnología biomédica pueden abordar la adquisición utilizando métodos de factores humanos, se aplicará el proceso de adquisición e implementación informado por factores humanos (HFPIP) a un estudio de caso (ver Estudio de Caso 2) que ocurrió en los Estados Unidos en el año 2000.

Estudio de caso 2. Sobredosis de morfina de Danielle McCray

Los eventos de este estudio de caso se describen en el libro El Factor Humano [9] y un artículo de revista publicado en el Canadian Journal of Anesthesia [84].

Después de revisar este caso, puede no parecer obvio cómo un error como este podría haber ocurrido. Una concentración de 5 mg / ml es obviamente más potente que una concentración de 1 mg / ml, y programar la bomba para una concentración inferior a la que

Factores humanos no considerados en el diseño de la bomba de analgesia controlada por el paciente

El 27 de febrero de 2000, a las 2:34 am, Danielle McCray, de diecinueve años de edad, fue admitida en el Tallahassee Memorial Hospital en Florida para tener a su bebé. Después de un largo parto, una niña sana nació por cesárea aproximadamente a las 4:30 PM. Alrededor de dos horas más tarde, Danielle se quejó de dolor, y a las 7:00 PM se conectó a una bomba de analgesia controlada por el paciente (PCA). Una bomba PCA es un tipo especial de bomba de infusión que ofrece pequeñas dosis de analgésicos a petición de un paciente a través de un botón remoto.

Una enfermera programó la bomba PCA para que Danielle pudiera autoadministrar pequeñas dosis de morfina según lo prescrito por su médico. A las 8:30 PM, Danielle estaba despierta, alerta, y alimentando a su recién nacida. Seis horas más tarde, tras un esfuerzo de reanimación de 30 minutos, Danielle había muerto.

Los resultados de la autopsia mostraron que Danielle había experimentado una sobredosis de morfina, con casi cuatro veces la dosis letal de morfina en su torrente sanguíneo. Tras una investigación adicional, se descubrió que la causa de la sobredosis era un error de programación. Específicamente, la enfermera programó la bomba para una concentración de morfina de 1 mg / mL, pero Danielle estaba recibiendo morfina a una concentración de 5 mg / mL. Esto significaba que cada vez Danielle pidió morfina, recibió una sobredosis de 5 veces mayor en comparación con la cantidad prescrita.

193

se carga significa que se libera más volumen del fármaco con cada dosis, lo que, dada la concentración utilizada, dará como resultado una sobredosis de medicación. Uno de los factores probables que contribuyen a este error es que en la configuración preestablecida de factores, la bomba ofrece secuencialmente cuatro ajustes de concentración predeterminados durante la secuencia de programación (morfina 1 mg / ml, morfina 5 mg / ml, morfina 0,5 mg / ml y meperidina 10 mg / ml). En este caso, la enfermera tenía que rechazar la primera opción predeterminada y seleccionar la segunda opción, pero lo más probable es que seleccionó la primera opción. El error de selección de concentración es más probable en este caso particular porque el hospital almacena 1mg / mL de morfina y 5mg / mL de morfina, pero la concentración de 1mg / mL no estaba disponible, por lo que la enfermera tuvo que obtener un contenedor de 5mg / mL. Es probable que 1 mg / ml de morfina sea la concentración estándar para los pacientes obstétricos y la enfermera esté condicionada a programar la bomba para 1 mg / ml de morfina (aunque estos hechos no se confirmaron en los informes).

Lo que hace que la muerte de Danielle sea aún más perturbadora, es que este modelo particular de la bomba de PCA había sido implicado en varios otros errores de programación de la concentración de morfina debido a la selección incorrecta de la concentración por defecto, llevando en última instancia a varias muertes de pacientes. Además, tres años antes de la muerte de Danielle, se emitió una alerta de dispositivo médico para la bomba debido al problema de concentración por defecto [85-87].

Desde entonces, los investigadores de factores humanos han estimado este modelo de bomba PCA, que ya no está disponible para la compra, fue responsable de entre 65 y 667 muertes debido a errores de programación [84]. Un análisis de factores humanos de la interfaz de usuario encontró que la secuencia de programación de la bomba PCA era compleja y confusa, requiriendo hasta 27 pasos de programación distintos para el funcionamiento correcto. Una interfaz rediseñada propuesta por investigadores de factores humanos requirió un máximo de sólo 12 pasos de programación en comparación. Un experimento controlado que comparaba los dos diseños mostró que el diseño informado por factores humanos condujo a menos errores, tiempos de finalización de tareas más rápidos y menor carga de trabajo mental [88].

Este incidente sirve para resaltar que los eventos adversos pueden esperarse cuando los dispositivos no han sido diseñados, seleccionados e implementados usando los principios de los factores humanos [84, 89-91]. Tal vez Danielle y otros estarían vivos hoy si el fabricante de la bomba PCA hubiera incorporado los métodos de factores humanos al diseñar la bomba PCA, o si el hospital hubiera sido capaz de incorporar factores humanos en el proceso de adquisición.

Para ilustrar cómo un profesional de la tecnología biomédica puede aplicar el HFPIP presentado en el Capítulo 11, este capítulo presenta un estudio de caso aplicando el marco para la adquisición de un nuevo tipo de bomba PCA para reemplazar los dispositivos PCA existentes de un hospital. La razón de ser de la compra era que los dispositivos PCA actuales eran muy viejos y cada vez era más difícil conseguir piezas de repuesto para el servicio de

194

las bombas. Adicionalmente, las bombas actuales tenían problemas de usabilidad que estaban implicados en varios incidentes de medicación que resultaron en daño al paciente.

Sección 12.1. Crear el equipo

Una vez que el hospital tomó la decisión de avanzar en la adquisición de una nueva bomba PCA, se creó un equipo multidisciplinario para realizar el HFPIP (Tabla 24). En este caso, el equipo consistió en representantes con las siguientes áreas de especialización:

Tabla 24. Equipo de decisión de adquisiciones del PCA

Interesados Directos Interesados Indirectos Anestesia Tecnología biomédica

Unidad de cuidados post-anestésicos Factores humanos

Personal de turno Educación Clínica

Manejo del dolor Manejo del riesgo

Farmacia Informática

Limpieza y mantenimiento Legal

Almacenamiento central

Administración hospitalaria

Los representantes clínicos incluidos en el equipo de HFPIP tuvieron en cuenta una

combinación de personal de primera línea y gerentes. En muchos casos también es ventajoso incluir un representante del paciente. La lista de las partes interesadas mencionadas anteriormente incluía partes interesadas directas e indirectas.

Sección 12.2. Establecer necesidades y deseos

Una vez que se estableció el equipo de adquisiciones, con el profesional en tecnología biomédica, el especialista en factores humanos y enfermera de la unidad de cuidados post-anestesia, el equipo HFPIP realizó observaciones (capítulo 4) de las bombas PCA actuales para saber más sobre los tipos de usuarios y cómo ese personal estaba interactuando con la bomba. Se llevaron a cabo entrevistas informales (capítulo 5) con el personal a medida que se hacían observaciones para recopilar información sobre los tipos de tareas que realizan, las características en las que se basan, las características que deseaban y las frustraciones generales con sus dispositivos actuales.

Se creó una lista de todos los grupos de usuarios que interactuaron con la bomba PCA actual y se completó un análisis de tareas (Capítulo 6) para describir las tareas realizadas con la bomba actual por cada grupo de usuarios. Después de la recopilación de datos y la documentación, se realizó otra ronda de entrevistas y grupos focales (Capítulo 5) con el

195

personal, para validar el análisis de tareas y para recopilar información sobre otras características y capacidades deseadas que una Bomba PCA ideal tendría.

El profesional de la tecnología biomédica del equipo de HFPIP revisó un HFRCA anterior (Capítulo 10) que había sido completado después de un incidente que involucraba las bombas PCA actuales del hospital. También se revisaron los sistemas internos y externos de notificación de incidentes para buscar incidentes relacionados con la bomba PCA.

Para cada grupo de usuarios, las necesidades y deseos establecidos se clasificaron en requisitos funcionales (lo que la bomba debe hacer) y consideraciones de implementación (lo que el hospital debe considerar y / o adaptar antes de implementar). Se identificó un pequeño subconjunto de las necesidades del usuario como resultado de este proceso (Figura 35).

Figura 35. Selección de necesidades y deseos de los usuarios divididos en requisitos funcionales y consideraciones de implementación.

Sección 12.3. Escribir y distribuir una RFP

Una vez que se establecieron las necesidades y deseos de cada grupo de usuarios, el equipo de adquisiciones escribió y distribuyó una solicitud de propuesta (RFP) a varios proveedores. Además de los componentes estándar de RFP, el equipo de HFPIP también incluyó una solicitud de documentación de cada proveedor describiendo cómo la norma de factores humanos HE75 [73] había sido interpretada e incorporada al diseño de la bomba PCA Tabla 23. En este caso, en lugar de destacar partes específicas de la norma en la RFP, se realizó una investigación más general utilizando la siguiente solicitud: "Por favor, indique cómo el diseño de la tecnología ha cumplido con la norma AAMI / ANSI HE75". Además, la RFP solicitó que el proveedor entregara evidencia de cómo los resultados de la prueba de usabilidad (Capítulo 8) fueron incorporados en el diseño del producto.

Grupo de usuarios 1:

Enfermeras de atención post-anestesia en el hospital

Requerimientos funcionales:

Debe ser capaz de administrar

(1) Una dosis única PCA

(2) Una dosos PCA continua, y

(3) Una dosis continua única

Debe ser capaz de conectar y deconectar fácilmente una bomba PCA a un

soporte IV

Debe tener una caja de seguridad robusta

196

La RFP también incluyó una descripción de los métodos de evaluación de factores humanos que se planificaron como parte del HFPIP (Figura 36).

Figura 36. Descripción de los métodos de factores humanos aplicables a las tecnologías preseleccionadas

Sección 12.4. Evaluación

El equipo de HFPIP recibió cuatro respuestas a la RFP. Después de revisar la propuesta de cada proveedor frente a la RFP y de reexaminar las necesidades y deseos de los usuarios establecidos anteriormente en el HFPIP, se encontró que tres de las cuatro propuestas de los vendedores cumplían con los requisitos esbozados en la RFP. Por lo tanto, las bombas PCA de cada uno de estos tres vendedores fueron preseleccionadas y avanzaron en la fase de evaluación del HFPIP, mientras que la bomba PCA del proveedor que no cumplía con los requisitos no avanzó más como parte del HFPIP.

Como se indica en la RFP, el equipo de HFPIP solicitó 3 bombas PCA y 50 conjuntos de mangueras primarias de cada proveedor de la lista corta para que el análisis heurístico y las pruebas de usabilidad pudieran tener lugar.

"Cada producto que se preselecciona para la evaluación se someterá a pruebas de factores humanos, que incluirán una evaluación heurística y pruebas de usabilidad. Los proveedores no serán invitados a participar directamente en estas evaluaciones, pero se espera que proporcionen a la organización de atención médica 3 bombas de PCA y 50 conjuntos de tubos primarios para permitir esta prueba. Es posible que se requiera apoyo adicional para capacitar al personal del equipo de adquisiciones que realizará estas evaluaciones. Por último, es posible que se requiera asistencia para cargar el software de biblioteca de medicamentos personalizado y para descargar bibliotecas de medicamentos específicas en las bombas de prueba.

Evaluación heurística: una evaluación heurística es una comparación estructurada de una interfaz de usuario o diseño de producto con principios de diseño de factores humanos establecidos o heurística [3]. Este método generalmente lo llevan a cabo uno o más expertos en usabilidad. Una evaluación heurística es útil para identificar problemas de diseño que pueden dar lugar a errores de uso.

Prueba de usabilidad: una prueba de usabilidad es un método de evaluación de factores humanos donde los usuarios finales representativos interactúan con un sistema en un entorno simulado. Se pueden recopilar datos de usuarios finales representativos sobre la seguridad, la idoneidad y la facilidad de uso de un sistema antes de su selección e implementación en el mundo real.

197

Sección 12.4.1. Análisis heurístico

El especialista en factores humanos llevó a cabo un análisis heurístico (Capítulo 7) utilizando el método heurístico de Zhang et al. para evaluar la usabilidad de la tecnología médica (Tabla 1), y luego dirigió a varios representantes clínicos a través de un análisis heurístico al sentarse con ellos y pedirles que completaran una amplia gama de tareas en la bomba PCA, mientras identificaban algo que parecía poco claro, extraño, o difícil. La lista de tareas se creó con base en el manual del usuario de cada bomba y los datos de observación recopilados durante la evaluación de las necesidades del usuario. Dado que no todas las bombas PCA tenían las mismas características, las listas de tareas eran algo diferentes para cada bomba, aunque había un conjunto común de tareas básicas en cada bomba. El especialista en factores humanos documentó el problema de diseño subyacente y las heurísticas que fueron violadas. Una vez que todas las tareas estuvieron completas, el representante de factores humanos revisó la lista de problemas con el clínico y pidió al clínico que identificara el impacto (el peor resultado posible) como resultado del problema. La gravedad de cada resultado se calificó utilizando criterios de calificación predefinidos similares a los mostrados en la Tabla 2.

Una lista de problemas de usabilidad considerados "severos" basados en los criterios de puntuación de la Tabla 2, se recopilaron a través de los análisis heurísticos realizados por cada miembro del equipo. Se identificó una lista de cambios o acciones recomendados para cada uno de estos temas. Una muestra de algunos de los problemas graves identificados en cada una de las tres bombas PCA se muestra en la Tabla 25.

Tabla 25. Una muestra de los problemas de usabilidad graves encontrados por cinco revisores independientes durante un análisis heurístico de las tres bombas PCA preseleccionadas

Bomba A Problema Heurística violada Cambios o acciones recomendados

La bomba puede comenzar a infundir con la tapa cerrada pero no bloqueada.

Evitar errores. Realimentación

La bomba debe tener un sensor en la cerradura, y no sólo la cubierta, para garantizar la seguridad dada la naturaleza de alto riesgo de los medicamentos como los narcóticos.

No se pueden cambiar los parámetros de entrega una vez que la bomba esté programada y funcionando. Los usuarios tienen que volver a programar toda la información y cualquier información de cambio se pierde.

Flexibilidad y eficiencia Los usuarios en control

La bomba debe permitir a los usuarios ajustar los parámetros una vez que esté funcionando. Un código o clave debe ser requerido.

198

Hay dos secuencias de tareas diferentes asociadas con el cambio de una jeringa, dependiendo de si el mismo medicamento se va a continuar o no

Minimizar la carga de memoria

Las secuencias de tareas para cambiar una jeringa deben ser consistentes independientemente de si una nueva jeringa contiene el mismo fármaco.

Bomba B

Problema Heurística violada Cambios o acciones recomendados La bomba no pide que el código de barras sea escaneado. La selección manual de fármacos es siempre disponible.

Prevenir errores

Una opción debe estar disponible para hacer que el código de barras sea escaneado en forma obligatoria antes de cargar la jeringa. El escáner debe detectar e indicar un defecto en el código de barras.

Después de escanear el código de barras, el nombre del fármaco y la concentración pueden ser manualmente cambiados

Prevenir errores

Una vez que se ha escaneado un código de barras, el menú de medicamentos sólo debe mostrar el medicamento escaneado. Todos los demás nombres de fármacos deben eliminarse.

La bomba no pide a los usuarios revisar sistemáticamente los ajustes antes de iniciar bomba.

Prevenir errores

En la pantalla de ejecución, los usuarios deben ser forzados a confirmar cada ajuste

Sólo hay un nivel de bloqueo que proporciona acceso a todas las funciones.

Prevenir errores

Crear al menos dos niveles de bloqueo, uno que desbloquea todas las funciones y una que desbloquea todo, menos el bolo clínico para que la enfermera de sala no puede dar accidentalmente bolos.

Cuando la bomba está desbloqueada con un código, permanece desbloqueado durante un minuto. Los pacientes podrían manipular la bomba durante este tiempo.

Prevenir errores

La bomba debe volver a bloquearse automáticamente una vez que se inicie el funcionamiento, o después de 30 segundos de estar inactivo durante la programación.

199

El límite de 4 horas no tiene unidades fijas. Los usuarios pueden seleccionar mcg / kg, mcg, mg / kg, mg.

Prevenir errores

Las unidades para el límite de 4 horas deben fijarse como parte del protocolo de drogas.

Bomba C Problema Heurística

violada Cambios o acciones recomendados

La tecla presionar tecla no está visible al usuario inmediatamente.

Retroalimentación Informativa

La CPU debe actualizar las pantallas mucho más rápido para prevenir que los usuarios de seleccionen el botón equivocado.

Los botones de la segunda pantalla deben estar cuidadosamente colocados de forma que al seleccionar un botón rápidamente dos veces seguidas (a) no seleccione nada (es decir, ningún botón en esa posición en la segunda pantalla) o (b) seleccione una segunda acción segura de la que sea fácil de salir de si se desea.

No hay manera clara de salir de la pantalla de Dosis del Bolo sin haberle suministrado un bolo al paciente . El usuario debe pulsar Cancelar dos veces para salir. La bomba no aceptará 0 mg.

Comportamiento reversible

Usuarios en control

Minimizar la carga de memoria

Proporcionar una salida clara (agregar la tecla "Salir" al fondo de la pantalla, con una pantalla pidiendo al usuario que confirme que no desea continuar con un bolo). Permitir que el usuario ingrese 0 mg como dosis y, de nuevo, confirmar que no están dando ninguna dosis antes de pedir al usuario que cierre y bloquee la puerta.

Sección 12.4.2. Pruebas de usabilidad

Tras el análisis heurístico de cada una de las tres bombas PCA, el especialista en factores humanos, profesional de la tecnología biomédica y enfermera de dolor agudo se prepararon y realizaron pruebas de usabilidad (Capítulo 8). Realizaron la prueba de usabilidad en una sala de pacientes vacía en la sala general de la organización de salud.

El ambiente se duplicó tanto como un entorno de trabajo y como una unidad de cuidados post-anestésicos (Figura 37).

200

Figura 37. Entorno de prueba de usabilidad para las pruebas de usabilidad de PCA

Sección 12.4.2.1 Preparación para pruebas de usabilidad

Los datos recogidos durante el proceso de (1) establecimiento de las necesidades y deseos del usuario (observaciones), (2) realización del análisis de tareas y (3) realización del análisis heurístico se utilizaron como base para desarrollar los escenarios de pruebas de usabilidad (Sección 8.5.2). Cada participante debía completar cuatro escenarios diferentes en cada boba para asegurar que la siguiente lista de tareas fue completada en cada bomba:

1. Configuración y programación de un PCA para un nuevo paciente

2. Sustitución de un recipiente de medicamento vacío y reinicio de la bomba

3. Cambiar a un nuevo medicamento y volver a programar la bomba

4. Titulación de la dosis y comprobación del historial de la medicación.

Se desarrollaron tres conjuntos de escenarios diferentes pero equivalentes para que los participantes pudieran completar el mismo conjunto de tareas en cada bomba, pero con un contexto diferente, de modo que la prueba de cada uno de los tres productos no parezca repetitiva o familiar.

La asignación de cada conjunto de escenarios a cada bomba fue contrabalanceada, al igual que el orden en que cada participante probó cada bomba. El esquema de equilibrio se muestra en la Figura 38. Para cada participante (es decir, Participante 1-10), el esquema ilustra el orden en el que se prueba cada bomba (por ejemplo, Primera A, Segunda B, Tercera C) y el grupo de escenarios aplicado a cada bomba es decir, S1, S2, S3).

201

Participantes de Gestión de Dolor Participantes de Unidad de Atención Post-Anestesia

Parte 1 Parte 2 Parte 3 Parte 4 Parte 5 Parte 6 Parte 7 Parte 8 Parte 9 Parte 10

Primero A/S1 B/S3 C/S2 A/S1 B/S3 C/S2 A/S1 B/S3 C/S2 A/S1

Segundo B/S2 C/S1 A/S3 B/S2 C/S1 A/S3 B/S2 C/S1 A/S3 B/S2

Tercero C/S3 A/S2 B/S1 C/S3 A/S2 B/S1 C/S3 A/S2 B/S1 C/S3

A 3, B, C = bomba A, bomba B, bomba C

S1, S2, S3 = Grupo de escenario 1, Grupo de escenario 2, Grupo de escenario

Figura 38. Asignación del orden de las bombas y grupos de escenarios a cada participante para lograr el contrapeso

Los escenarios de usabilidad fueron revisados con miembros clínicos del equipo de HFPIP, incluyendo aquellos de la anestesia, la unidad de cuidado post-anestesia, el manejo del dolor, el pabellón general y la educación clínica, para asegurar que eran lo más realistas posible. Dos de los escenarios de prueba de usabilidad que se desarrollaron se incluyen en la Figura 39 como un ejemplo.

Escenario Grupo 1 Escenario 1: Configuración de un nuevo paciente para Infusion PCA Nuevo paciente, el Sr. Ricard llega a la unidad de cuidados post-anestésicos (PACU)

después de una cirugía de reemplazo total de cadera. El paciente tiene 76 años y es estable. Su nivel de dolor es 6/10 cuando descansa.

Tarea 1: Programe la bomba PCA para que el paciente reciba 2mg / ml de morfina a una dosis continua de 5mg / h con una dosis en bolo de 2mg. El tiempo de bloqueo del bolo es 5 min. y el límite de 4 horas es 40 mg.

Escenario 2: Reemplazar un contenedor de medicamentos vacío El Sr. Ricardi está listo para mudarse de la PACU a la sala. Al llegar al pabellón, usted nota

que el contenedor de morfina en la bomba está casi vacío. Tarea 2: retire el contenedor de medicamentos vacío, reemplace con uno nuevo y vuelva

a encender la bomba. Escenario 3: Cambiando a un nuevo medicamento El Sr. Ricardi, está empezando a quejarse de que le pica. Usted nota que está desarrollando

ronchas en su torso y se están extendiendo. Usted habla con su esposa y ella dice que tuvo una reacción similar a la morfina cuando se cayó y se lastimó la cadera varios años atrás. Aunque su cuadro no tiene alergias eregistradas, usted consulta con el médico y ella decide cambiarlo a hidromorfona.

Tarea 3: Cambiar el contenedor de medicamento de morfina a hidromorfona, reprogramar e iniciar la bomba.

Escenario 4: Titular la infusión y documentar los totales del turno Alrededor de una hora después de que se inició la hidromorfona, el nivel del dolor del Sr.

Ricardi sigue siendo 5/10. Su ritmo cardíaco es elevado y se siente visiblemente incómodo. Sus órdenes de medicamentos permiten aumentar la dosis continua de hidromorfona de 1 mg/hr 1,5 mg/hr. Como se encuentra al final de su turno, decide documentar primero los totales de su turno y luego titular la hidromorfona.

Tarea 4: Documente los totales de turnos en el registro de administración de medicamentos, y luego titule la hidromorfona.

202

Figura 39. Escenarios en el grupo de escenarios 1 para las pruebas de usabilidad de PCA

Una vez finalizados los escenarios, se escribieron guiones para facilitar cada tarea. Un ejemplo de script basado en el primer escenario de la Figura 39 se muestra en la Figura 40. También se desarrolló una herramienta de documentación de datos (Sección 8.5.4) basada en las tareas y subtareas de cada escenario.

Cada una de las tres bombas PCA se personalizó para adaptarse a los escenarios de usabilidad y grupos de usuarios. En este caso, la biblioteca de fármacos para cada bomba se personalizó para que coincida con los fármacos y las concentraciones dadas por PCA en salas y en la unidad de cuidados post-anestésicos. Se incluyeron en el estudio a usuarios finales representativos, incluyendo anestesistas, enfermeras de la unidad de cuidados post-anestesia, enfermeras de manejo del dolor y enfermeras de la sala general. Se contactó a los vendedores de cada una de las tres bombas PCA para obtener asistencia en la creación de bibliotecas de fármacos apropiadas para cada uno de estos cuatro servicios.

Figura 40. Script desarrollado en base a los escenarios de prueba de usabilidad

[Actor de Enfermera] "Hola, soy Carol, encantada de conocerle. Gracias por venir habiéndole llamado con poca antelación, hemos estado inundados toda la mañana y nuestra enfermera de recursos no se presentó. Acabamos de tener 3 pacientes provenientes de la sala de operaciones y todos ellos necesitan comenzar con sus medicamentos de inmediato. Ya que no ha trabajado en esta unidad antes, hay un par de cosas que le mostraré antes de que arranque una de nuestras PCA. Primero, aquí está nuestro carro de la administración de la medicación donde usted puede encontrar los expedientes del paciente y los pedidos de la medicación. Usted será responsable de administrar los medicamentos IV, pero puedo facilitarle cualquier documentación. Hay un formulario de medicamentos IV en la carpeta en el carro si lo necesita, y también se puede acceder en línea ".

¿Alguna pregunta?" [Participante] "No ... nada que se me ocurra ahora ..." [o responder cualquier

pregunta que tengan] [Actor de enfermera] "Genial! empecemos. Nuestro primer paciente es el Sr.

Ricardi. Él es un hombre de 76 años de edad que se sometió a un reemplazo total de cadera. No hay complicaciones o antecedentes médicos relevantes para reportar. Su frecuencia cardíaca es 62, su frecuencia respiratoria es 14, su temperatura es 37.8 ° C, y su presión arterial es 110/70. Está consciente, pero actualmente duerme y se queja de dolor postoperatorio (6/10 en reposo y no ha intentado moverse). Necesita comenzar con una IV desde la l PCA. Sus órdenes de morfina están en su historia.

Yo voy a estar allí con la Sra. Wu así que llame si necesita algo, pero confío que usted estará bien por su cuenta.

[Participante]: Seguro [Actor de Enfermera]: Genial, gracias! Volveré en un momento.

203

Los cuestionarios previos y posteriores (Figura 41 y Figura 42) fueron diseñados con el fin de recoger retroalimentación directa e información de cada grupo de usuarios representativo.

Figura 41. Ejemplo de cuestionario previo para la prueba de usabilidad de la bomba PCA

Datos Demográficos 1. Cómo se describe mejor su papel en el hospital?

Médico

Enfermera registrada

Oto:_________________

2. Cuál e su edad?

18 – 29 años

30 – 39 años

40 - 49 años

50 - 64 años

65 años o más

3. Hace cuánto desempeña ese papel?

Menos de un año

1 a 4 años

5 a 9 años

10 a 20 años

Más de 20 años

4. En que unidades trabaja habitualmente? (identifique todas las que apliquen)

Consulta Externa

Emergencia

Cirugía

Unidad Pediátrica de Cuidado Intensivo

Unidad Neonatal de Cuidado Intensivo

Unidad Quirúrgica de Cuidado Intensivo

Unidad de Cuidado Post-anestesia

Otra:______________

5. Cuánto hace que trabaja en el área clínica en que está ahora?

Menos de un año

1 a 4 años

5 a 9 años

10 a 20 años

Más de 20 años

Conocimiento y Experiencia 1. Conóce una bomba PCA (Controlada por el Paciente)?

Si

No

2. Ha usado una bomba PCA antes?

Si

No

No estoy segura

3. Ha recibido alguna vez entrenamiento para usar una bomba de infusión PCA?

Si

No

No estoy segura

4. En general, cuál es su método preferido para aprender a utilizar un dispositivo médico? (Califique de 1 a 6, siendo 1 la más preferida y 6 la menos preferida)

Leer acerca del dispositivo

Asistir a una demostración práctica

Asistir a una conferencia o seminario

Tener acceso al dispositivo para practicar por si

misma y luego hacer preguntas según sea

necesario

Trabajar lado a lado con un colega experto

Ver un video de entrenamiento

204

Figura 42. Ejemplo de post-cuestionario para la prueba de usabilidad de la bomba PCA

Realimentación de Participantes

1. Usar esta bomba PCA fue intuitivo:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ________________________________________

2. Tengo inquietudes acerca de usar esta bomba PCA en mi entorno clínico:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ________________________________________ 3. Esta bomba PCA facilitará mi trabajo como

practicnte:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ________________________________________

4. Usar esta bomba PCA cambiará cómo pienso acerca de hacer infusiones:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionals:____________________ ________________________________________

5. Usar esta bomba PCA en mi unidad ayudará a mejorar la seguridad del paciente:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionals:____________________ ________________________________________

6. Me pareció que el conjunto de tareas durante el escenario fue difícil de completar:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ________________________________________

7. Estoy segura de haber completado todas las tareas durante el escenario:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ________________________________________

8. El entrenamiento que recibí fuú suficiente para permitirme completar todos los escenarios:

Completamente de acuerdo

De acuerdo

No me decido

En desacuerdo

Totalmente en desacuerdo

Comentarios adicionales:____________________ ________________________________________

205

El protocolo de entrenamiento para la prueba fue desarrollado por miembros del equipo de HFPIP. En primer lugar, los miembros del equipo HFPIP recibieron capacitación de cada uno de los proveedores en el nivel de profundidad que normalmente sería dado por el proveedor durante un servicio. El equipo de HFPIP entonces desarrolló un protocolo de entrenamiento para la prueba de usabilidad que incluía toda la información requerida para completar cada uno de los escenarios. La longitud y profundidad del protocolo de entrenamiento para la prueba de usabilidad fue similar en las tres bombas.

También se crearon guiones introductorios y formularios de consentimiento para asegurar que cada participante recibiría toda la información necesaria antes del inicio de la sesión de prueba de usabilidad.

Para las pruebas, un total de cinco enfermeras de la unidad de cuidados post-anestesia y cinco enfermeras / enfermeras practicantes del equipo de dolor agudo fueron reclutados.

Se completaron dos pruebas piloto de usabilidad: una con la enfermera de dolor agudo del equipo de HFPIP; Y uno con la enfermera de la sala general del equipo de HFPIP, para asegurarse de que todo se había organizado adecuadamente y estaba listo para funcionar. El especialista en factores humanos y profesional de la tecnología biomédica llenó la lista de comprobación de la prueba de usabilidad (Sección 8.5.13) antes de realizar la primera sesión oficial de prueba de usabilidad.

Sección 12.4.2.2 Realización de pruebas de usabilidad

Al llegar, cada participante fue bien recibido por el facilitador. El facilitador entregó el guión introductorio (Sección 8.5.8) y revisó el formulario de consentimiento (Apéndice A) con el participante y luego pidió al participante que completara la encuesta de pre-usabilidad (Figura 41). El facilitador entonces entregó el entrenamiento asociado con la primera bomba que se estaba probando al participante.

Después de la sesión de entrenamiento para esa bomba, el facilitador introdujo al participante en el primer escenario actuando como enfermera de actor (confederado) y el participante completó los cuatro escenarios de prueba asociados con cada bomba. La prueba fue filmada usando una cámara de video en un trípode. Un estudiante de tecnología biomédica ayudó a hacer la grabación de video durante las sesiones. Durante la prueba, el especialista en factores humanos documentó cualquier problema que se observó o acciones que fueron inesperadas en la hoja de documentación de datos. Después de completar los escenarios, el facilitador pidió al participante que llenara el cuestionario post-entrenamiento (Figura 42), y realizó una sesión informativa informal. Este proceso se repitió en las otras dos bombas PCA utilizando los otros dos grupos de escenarios para minimizar la familiaridad con las tareas. Al final de la prueba de usabilidad, después de probar las tres bombas, se llevó a cabo una sesión informativa ligeramente más larga con el participante para reunir más ideas generales sobre la sesión de prueba y las tres bombas PCA utilizadas.

El equipo de prueba de usabilidad analizó los datos recolectados de las sesiones de prueba de usabilidad evaluando el rendimiento y las preferencias del usuario para cada una de las tres bombas PCA (Sección 8.7.1). Los datos de rendimiento se utilizaron para

206

determinar los problemas y su gravedad. Los datos de preferencia se utilizaron para identificar cualquier problema potencial adicional o las necesidades de los usuarios que no se habían capturado previamente.

Los cuestionarios y las notas tomadas durante cada sesión de usabilidad se recopilaron entre los participantes. Las hojas de cálculo de documentación de datos que se completaron durante las pruebas también se recopilaron entre los participantes y se determinó qué tareas se pasaron y cuáles fallaron. Las tareas que los participantes tuvieron dificultades para completar fueron consideradas con mayor profundidad por el equipo de HFPIP.

Los resultados de las pruebas de usabilidad descubrieron varios problemas nuevos y validaron muchos de los hallazgos del análisis heurístico. Cada error se calificó usando una escala de gravedad similar a la de la Tabla 11, con los errores más severos extraídos y compilados para cada una de las tres bombas PCA ensayadas (Tabla 26). Se utilizaron estadísticas descriptivas para resumir el desempeño del usuario en cada bomba, por ejemplo, cuántos errores ocurrieron en cada tarea para cada bomba y, de éstos, cuántos tuvieron consecuencias potencialmente dañinas.

Tabla 26. Resumen de los problemas con consecuencias de seguridad potencialmente graves identificadas durante las pruebas de usabilidad

Bomba A

Problema Descripción del error Impacto en la seguridad Mecanismo de entrada (Rueda) no es intuitivo

El usuario selecciona el medicamento equivocado, (Ya sea porque presionan la rueda tratando de desplazarla, o accidentalmente presionan y giran la rueda al mismo tiempo).

El paciente recibe sobre / sub infusión dependiendo de la relación de concentración a dosis si el usuario no detecta el error.

La terminología de la bomba es inconsistente con la terminología usada en la organización de la asistencia sanitaria.

El usuario establece la "flujo de fondo" a 1,0 mg / hr en lugar de la dosis en bolo.

El paciente recibe más de infusión. Las consecuencias dependen de la tasa ingresada pero podrían ser severas.

Fallo técnico del software.

Cuando la bomba es encendida por primera vez, los totales que muestran son 0,0 mg,

Consecuencias poco claras pero podría potencialmente dar lugar a un seguimiento incorrecto del volumen de fármaco administrado, lo que podría conducir a cambios

207

42,2 ml. Ambos deben ser cero.

inadecuados en el orden de medicación.

Los usuarios no pueden recordarla secuencia de tareas para cambiar una jeringa a un nuevo fármaco, ya que es diferente que el cambio de una jeringa cuando el fármaco sigue siendo el mismo.

Al cambiar la jeringa a una con nuevos fármacos, los usuarios olvidaron detener la bomba para acceder a la lista de medicamentos. Un usuario cambió una jeringa a un nuevo fármaco, pero mantuvo el antiguo protocolo de fármacos.

El nuevo fármaco puede aplicarse, siguiendo el protocolo anterior. El paciente recibiría una infusión de más o menos dependiendo de la relación de concentración a dosis.

El usuario no está obligado a verificar la configuración.

El usuario no verificó cada parámetro seleccionado. Se desplazaron directamente a Confirmar.

Los parámetros del protocolo podrían ser incorrectos. La gravedad del impacto depende del rango de valores permitidos para el protocolo.

Bomba B

Problema Descripción del error Impacto en la seguridad Escáner de código de barras difícil de activar.

El usuario no tiene éxito en escanear el código de barras (no mantenerlo en la posición correcta después de presionar el mando superior).

Selección manual de fármacos permite el potencial para que la droga equivocada sea seleccionado. El paciente podría recibir sobre / sub infusión dependiendo de la relación de concentración a dosis.

El usuario no recibe alerta de que la bomba está funcionando.

La bomba se detiene y el usuario no la reinicia. El usuario piensa que la bomba está funcionando.

El paciente no recibe medicación.

La terminología de la bomba es inconsistente con la experiencia del usuario.

El usuario aumenta la dosis en bolo a 1,5 mg en lugar de la dosis de PCA porque interpreta el bolo como la dosis de PCA.

El paciente no recibe el aumento de dosis.

208

No está claro cómo borrar los totales del turno

El usuario da un bolo clínico al intentar borrar los totales de turno.

El paciente recibe una dosis que no está incluida en el límite de 4 horas y que no está prescrita.

Fácil de confundir modalidades, ya que se seleccionan con un botón.

El usuario purga accidentalmente la bomba después de conectarla al paciente mientras intenta arrancarla.

El paciente recibe una dosis que no está incluida en el límite de 4 horas y que no está prescrita.

El usuario no está alertado de que la bomba no está funcionando

El usuario programó la bomba, pero no presionó inicio. La bomba no estaba funcionando pero el usuario pensó que si lo estaba.

El paciente no recibe medicación.

Bomba C Problema Descripción del error Impacto en la

seguridad No está claro para los usuarios qué es el "Modo de Anestesia" o cómo afecta la bomba.

El usuario selecciona incorrectamente "Opciones" al intentar revisar los parámetros de configuración. El usuario selecciona "Modo Anestesia" y lo habilita sin saber lo que hace.

El paciente podría recibir una sobredosis ya que los límites de medicación se amplían en este modo.

Los botones de la bomba son difíciles de presionar.

El usuario introdujo una dosis de 0,2 mg, pero la bomba registró sólo 2 porque los botones son difíciles de presionar. El usuario notó y mitigó el error.

Si una dosis de 2 mg está dentro del límite de programación, se produciría una sobredosis de 10 veces cada vez que el paciente pidiera una dosis.

Efecto de paralaje visual en la pantalla de la bomba

El usuario seleccionó el medicamento equivocado tres veces debido a un efecto de paralaje en la pantalla de la bomba. Si el usuario no está parado directamente en frente y a la misma altura que la pantalla, los botones no se

Bomba programada incorrectamente, dando como resultado una sobre / sub infusión

209

alinean con las opciones de pantalla.

La respuesta de la bomba a una tecla presionada es retrasada.

El usuario presionó el mismo botón varias veces porque la bomba no respondió rápidamente a las pulsaciones de tecla iniciales. Pulsaciones subsiguientes se aplicaron a las pantallas siguientes sin que el usuario supiera qué fue seleccionado. En un caso, el usuario dio inadvertidamente al paciente un bolo de 1,5 mg debido a este problema de diseño.

Sobredosis no intencionadas.

El equipo de HFPIP revisó cada uno de los problemas de la Tabla 26 y discutió posibles

estrategias de mitigación para cada uno de ellos para ver si los riesgos podrían ser abordados de una manera sistemática antes de la implementación. Se compararon los riesgos que no se podían mitigar adecuadamente (es decir, se mitigaron utilizando un enfoque de sistemas en lugar de un enfoque de persona como se describe en la jerarquía de efectividad) en las tres bombas para identificar cuál de las tres bombas era la más segura y la más adecuada para la organización. La Tabla 27 muestra las estrategias de mitigación que fueron identificadas para los problemas asociados con cada una de las tres bombas.

Tabla 27. Estrategias de mitigación de estrategias para los problemas graves identificados durante las pruebas de usabilidad

Bomba A Problema Descripción del error Impacto de seguridad Estrategia de

mitigación

Terminología de la bomba inconsistente con la terminología utilizada en la organización de la salud.

El usuario ajusta la "Tasa de fondo" a 1,0 mg / h en lugar de la dosis en bolo

El paciente recibe más medicamentos para el dolor que los prescritos. Las consecuencias dependen de la tasa ingresada pero podrían ser severas.

Cambiar el texto de la orden de medicamentos pre-impresa para que coincida con la terminología de la bomba

Software técnico Cuando la bomba es

encendida por primera vez, los

Las consecuencias no son claras, pero podría

No hay una estrategia mitigadora eficaz

210

totales muestran 0,0 mg, 42,2 ml cuando deberían estar en cero.

potencialmente resultar en un seguimiento incorrecto del volumen de fármaco administrado.

desde dentro de la organización.

Asegúrese de que el proveedor solucione el fallo de la tecnología

La secuencia de tareas para cambiar una jeringa a una nueva droga es diferente que cambiar una jeringa cuando el fármaco sigue siendo el mismo.

Al cambiar la jeringa a un nuevo fármaco, los usuarios olvidaron detener la bomba con el fin de acceder a la lista de medicamentos. Un usuario cambió una jeringa a un nuevo fármaco, pero mantuvo el antiguo protocolo de fármacos.

El nuevo medicamento puede circular utilizando el protocolo de fármaco anterior. El paciente recibiría una infusión de más o menos dependiendo de la relación de concentración a dosis.

No hay una estrategia de mitigación efectiva desde dentro de la organización. Recomendamos que el proveedor revise el flujo de trabajo y mejore la coherencia. Recomendar que el vendedor revise la secuencia de tareas y mejore la consistencia.

Bomba B Problema Descripción del error Impacto de seguridad Estrategia de

mitigación

El usuario no es alertado si la bomba está programada pero no está funcionando.

La bomba se detiene y el usuario no la reinicia. El usuario piensa que la bomba está funcionando.

El paciente no recibe el medicamento, pero el usuario piensa que está fluyendo

Ninguna estrategia mitigadora efectiva desde dentro de la organización. Recomiende que el proveedor revise las alertas

Secuencia de tareas para borrar los totales del turno no es intuitiva.

El usuario da un bolo clínico accidental al tratar de borrar los totales del turno.

El paciente recibe una dosis que no está incluida en el límite de 4 horas y no está prescrita.

Ninguna estrategia eficaz de mitigación desde dentro de la

organización. Recomendar que el proveedor revise la estructura del menú de las opciones de usuario.

Fácil de confundir modalidades ya que se seleccionan con una perilla

El usuario purga accidentalmente la bomba después de que se conectó al

El paciente recibe una dosis que no está incluida en el

Ninguna estrategia eficaz de mitigación dentro de la organización.

211

paciente, al tratar de arrancar la bomba.

límite de 4 horas y no está prescrita.

Recomendar al proveedor la revisión del diseño de la tecnología para asegurarse de que los usuarios son conscientes de cuál modalidad ha sido seleccionada

Bomba C Problema Descripción del error Impacto de seguridad Estrategia de

mitigación

No está claro para los usuarios qué es el "Modo de anestesia" o cómo afecta a la bomba

El usuario selecciona incorrectamente "Opciones" al intentar revisar los parámetros de configuración. El usuario selecciona "Modo Anestesia" y lo habilita sin saber lo que hace.

El Modo de anestesia elimina muchos de los límites de seguridad incorporados en las plantillas de fármacos. Este modo podría ser removido de la bomba por lo que esta opción nunca sería inadvertidamente seleccionada.

Quitar el Modo de Anestesia desde la plantilla de biblioteca de fármacos para evitar este error de uso, ya que no es necesario para PCA.

Los botones de la bomba son difíciles de presionar.

El usuario ingresó una dosis de 0,2 mg, pero la bomba sólo registró 2 porque los botones son difíciles de presionar. El usuario notó y mitigó el error.

Si se toma una dosis de 2 mg dentro del límite de programación, se produciría una sobredosis de 10 veces cada vez que el paciente pidiera una dosis.

No hay una estrategia efectiva de mitigación desde dentro de la organización. Recomiende que el fabricante revise el diseño del botón para reducir la fuerza necesaria para registrar la presión de una tecla

Efecto de paralaje visual en la pantalla de la bomba.

El usuario seleccionó drogas equivocadas tres veces debido a un efecto de paralaje en la pantalla. Si el usuario no está parado frente, y a la

Bomba programada incorrectamente, resultando en infusión de más / o de menos

No hay estrategia efectiva de mitigación desde dentro de la organización. Recomendar que el proveedor revise el

212

misma altura que la pantalla, los botones no se alinean con las opciones de pantalla.

diseño de la pantalla para reducir el efecto de paralaje.

La respuesta de la bomba a la pulsación de las teclas es retrasada.

El usuario presionó el mismo botón varias veces porque la bomba no respondió rápidamente a las pulsaciones iniciales de tecla. Subsecuentes presiones de las teclas se aplicaron a las siguientes pantallas sin que el usuario supiera lo que había seleccionado. En un caso, el usuario dio inadvertidamente al paciente un bolo de 1,5 mg debido a este problema de diseño

Se hicieron selecciones incorrectas que pudieron resultar en darle medicamentos al paciente inadvertidamente.

Ninguna estrategia eficaz de mitigación dentro de la organización. Recomienda que el proveedor revise el diseño de los botones.

Durante este HFPIP, no se realizaron ensayos HFFMEA (Capítulo 9) ni ensayos en uso (Sección 11.6.2.4). Dado que la política de la organización sanitaria lo permitía, el equipo de HFPIP compartió algunas sugerencias con cada proveedor para resaltar los problemas de diseño que fueron descubiertos en su producto durante el proceso de evaluación. El equipo fue extremadamente cuidadoso al compartir los resultados, asegurando que la información fue mantenida confidencial entre el equipo de HFPIP y cada vendedor individual.

Además de las mencionadas evaluaciones informadas de factores humanos, el departamento de tecnología biomédica llevó a cabo evaluaciones técnicas de cada bomba para confirmar que cada bomba PCA funcionaba según las especificaciones. Los tres productos cumplían con las especificaciones técnicas, y no se eliminaron productos sobre esta base.

El departamento de compras del hospital también realizó una revisión financiera de cada producto. La bomba C fue más costosa que la bomba A o la bomba B, y quedó fuera del presupuesto del hospital, sin embargo este proveedor indicó una voluntad de negociar el

213

precio a cambio de ser un sitio de prueba beta si había interés en la compra del producto. No se eliminaron productos de la evaluación basándose en preocupaciones financieras.

Sección 12.5. Decidir sobre el (los) producto (s)

Para tomar la decisión final sobre qué bomba de PCA adquirir, el equipo de HFPIP pesó varios factores, incluyendo los hallazgos de las evaluaciones de factores humanos, y las revisiones técnicas y financieras. Dado que no existían limitaciones técnicas o de coste importantes, los factores diferenciadores más significativos fueron los resultados de las evaluaciones de factores humanos. Cada una de las tres bombas PCA que se consideran tenían problemas de seguridad que no podían ser efectivamente mitigados por la organización sanitaria. Dado que estas cuestiones tenían el potencial de causar graves daños al paciente, se inició una discusión con cada uno de los tres proveedores para determinar si el software y otros cambios de diseño podrían hacerse para abordar las preocupaciones. Ninguno de los tres proveedores pudo realizar los cambios solicitados y, por lo tanto, el equipo HFPIP decidió no comprar ninguna de las tres bombas PCA evaluadas.

Los fondos disponibles para el gasto de capital fueron mantenidos por la organización de salud, y la decisión de compra se aplazó durante aproximadamente un año. Durante este tiempo, otro proveedor introdujo una nueva bomba de PCA en el mercado que estaba bajo licencia para la venta y que cumplía con los criterios establecidos en la RFP. El equipo de HFPIP evaluó la nueva bomba PCA usando el mismo proceso descrito en este capítulo. Los resultados de las evaluaciones de factores humanos mostraron menos problemas de usabilidad y ninguno de los problemas identificados tuvieron serias implicaciones de seguridad. El equipo de HFPIP seleccionó esta bomba (bomba D) para la adquisición.

Se reconoce que muchos hospitales están obligados a tomar decisiones de compra basadas principalmente en el costo. En estos casos, es aún más importante asegurar que las necesidades de los usuarios, particularmente aquellas relacionadas con las características y funciones del producto que puedan afectar la seguridad, se traduzcan directamente en la solicitud de propuestas para que los productos que no soportan un uso seguro puedan eliminarse de la convocatoria. Si la decisión final está determinada principalmente por el costo, se recomienda que se lleve a cabo una evaluación de la usabilidad de ese producto para identificar problemas potenciales y requisitos de capacitación para que se puedan desarrollar estrategias de mitigación y capacitación apropiada como parte de la estrategia de implementación.

Sección 12.6. Configurar los productos y el entorno

Los hallazgos de las evaluaciones de factores humanos realizadas en la bomba D se utilizaron para ayudar a informar cómo configurar la bomba para cada grupo de usuarios representativo. Por ejemplo, los ajustes de alarma se ajustaron en base al número de alarmas de aire-en-línea experimentadas durante las pruebas de usabilidad. Además, los pedidos de medicamentos preimpresos fueron rediseñados para asegurar que el texto coincidía con el texto utilizado en la bomba y el orden de información en el formulario de pedido preimpreso era coherente con las secuencias de programación para minimizar los errores de entrada de datos.

214

Sección 12.7. Planificar e implementar producto (s)

Realización de cambios en el sistema de trabajo

Los hallazgos de las evaluaciones de factores humanos llevadas a cabo en la bomba D se utilizaron para ayudar a informar los tipos de cambios requeridos a nivel del sistema de trabajo. Por ejemplo, se implementó una hoja de trabajo para ayudar a apoyar y guiar a las enfermeras a través de algunos nuevos pasos de documentación que se requerían para verificar los derechos de administración de medicamentos [92, 93] y los lugares de almacenamiento de tubos intravenosos para bombas PCA y bombas de infusión de gran volumen se cambiaron debido a una falla cercana durante las pruebas de usabilidad donde el tubo incorrecto fue casi utilizado por un participante.

Entrenamiento y educación

Se ofrecieron varias sesiones de capacitación al personal, comenzando unos meses antes de la fecha en que se iba a implementar la bomba PCA. Los miembros del equipo de HFPIP, incluyendo el educador clínico, crearon un programa de capacitación adaptado a las necesidades de cada grupo de usuarios representativo. El representante de los factores humanos también fue muy instrumental en el diseño de la capacitación y comunicó qué aspectos de la bomba necesitaba destacarse en la capacitación sobre la base de los resultados de las pruebas de usabilidad. El entrenamiento fue administrado conjuntamente por el vendedor y el educador clínico. Se presentó información no sólo sobre ‘saber de botones’ (por ejemplo, qué botón presionar para iniciar la bomba PCA), sino también los principios subyacentes que rigen cómo funciona la bomba PCA para que el personal entienda por qué un proceso tenía que hacerse de una manera determinada. "Clínicas de capacitación" prácticas se llevaron a cabo periódicamente hasta la fecha de implementación para que el personal pueda practicar el uso de la bomba PCA en un entorno simulado. Antes de recibir la aprobación para usar la bomba PCA en la práctica, cada usuario final tuvo que completar con éxito un conjunto de tareas prácticas para demostrar su capacidad para realizar cada tarea requerida.

Implantación

La nueva bomba PCA fue implantada por la organización de salud, y aunque la transición fue algo estresante para el personal, campeones clínicos altamente capacitados en cada unidad estaban disponibles para apoyar al personal durante la implementación.

Apoyo transitorio y continuo

Incluso después de que se implementaron las bombas de PCA, se llevaron a cabo ocasionalmente "clínicas de entrenamiento" donde el personal podía venir a practicar en la nueva bomba PCA en un ambiente simulado. Se estableció un programa de capacitación por

215

competencias en la institución de salud para que el personal pudiera revisar regularmente los requisitos al usar estas bombas y el nuevo personal podría ser entrenado de manera sistemática.

La implementación fue muy exitosa. Las enfermeras transitaron a los nuevos dispositivos con facilidad, y las bombas fueron utilizadas con seguridad y eficacia por todos los grupos de usuarios.

216

Capítulo 13. Identificación de Problemas e Investigación de Incidentes. Caso de Estudio

Los profesionales de la tecnología biomédica son a menudo los primeros en identificar problemas con una tecnología. A veces los identifican proactivamente, durante las inspecciones regulares, y a veces los encuentran retrospectivamente, cuando son contactados por el personal de primera línea para recibir ayuda. En ambos escenarios, los profesionales de la tecnología biomédica están bien posicionados para aplicar métodos de factores humanos para identificar problemas de factores humanos. Este capítulo utilizará casos de estudios para mostrar dos métodos informados con factores humanos que pueden usarse para ayudar a identificar problemas de factores humanos con tecnología ya sea retrospectivamente (HFRCA) o prospectivamente (HFFMEA).

Sección 13.1. Investigaciones de incidentes en retrospectivas: HFRCA

Para ilustrar cómo el profesional de la tecnología biomédica puede abordar las investigaciones de incidentes desde una perspectiva de factores humanos, se aplicará el marco de análisis de causa raíz (HFRCA) de factores humanos a un caso de estudio (Caso de estudio 3) que ocurrió en Canadá en 2006.

Sobredosis de quimioterapia resulta en la muerte del paciente

El 31 de julio de 2006, una mujer de 43 años se sometió a su primer ciclo de tratamiento quimioterápico adyuvante intravenoso (IV) para reducir la probabilidad de recurrencia del cáncer nasofaríngeo. Anteriormente, había recibido dos meses de tratamiento combinado de quimioterapia y radioterapia, y aunque su cáncer estaba avanzado, se esperaba que el tratamiento planificado fuera efectivo.

En la mañana de su primer ciclo de tratamiento adyuvante, llegó al centro de cáncer y recibió medicamentos de hidratación y anti-náuseas por vía intravenosa, seguido de la quimioterapia intravenosa, el cisplatino. Este fármaco fue seguido por una medicación post-hidratación y otro fármaco de quimioterapia, fluorouracilo. Una dosis alta de fluorouracilo debía administrarse al paciente lentamente, durante el transcurso de cuatro días. Así que el paciente no tendría que permanecer en el hospital para esta infusión, el fluorouracilo debía administrarse por vía intravenosa usando una bomba de infusión ambulatoria.

La enfermera calculó la dosis requerida de suministro de medicación para el fluorouracilo, programó la bomba de infusión ambulatoria y pidió a una segunda enfermera que comprobara su cálculo y que la bomba había sido programada correctamente. Ambas enfermeras firmaron en la documentación requerida, y la enfermera del paciente conectó al paciente a la bomba de infusión ambulatoria y comenzó la infusión. La enfermera instruyó al paciente para que regresara en cuatro días, momento en el cual se desconectaría de la bomba de infusión ambulatoria.

217

La paciente salió de la clínica, y unas cuatro horas después escuchó un pitido de la bomba de infusión. Cuando comprobó la bomba, vio que toda la bolsa de fluorouracilo ya estaba vacía. En lugar de infundir durante cuatro días, la medicación había sido entregada a la paciente en sólo cuatro horas.

La paciente volvió al centro del cáncer donde la bomba fue desconectada y su línea fue lavada. El médico de turno fue notificado e indicó que desafortunadamente no se podía hacer nada para revertir la sobredosis, ya que no había antídoto. Trágicamente, el paciente murió el 22 de agosto de 2006 de "causas complejas, incluyendo falla de múltiples órganos, así como sangrado interno generalizado ".

De: ISMP Canadá Fluorouracil Incident Root Cause Analysis, mayo de 2007. Disponible

En https://www.ismp-canada.org/download/reports/FluorouracilIncidentMay2007.pdf

Caso de Estudio de 3. Sobredosis de quimioterapia que provoca la muerte del paciente

Poco después de este trágico incidente, se pidió a ISMP Canadá que investigara e identificara los factores subyacentes que podrían haber contribuido al evento, con la esperanza de que otros eventos similares pudieran prevenirse en el futuro. En consecuencia, cuando un evento centinela ocurre en su propia organización de atención médica, se recomienda que se complete un HFRCA, no sólo para cumplir con los requisitos legales o de acreditación, sino también para reducir la probabilidad de que de nuevo ocurran otros eventos similares.

Antes de llevar a cabo un HFRCA, el profesional de la tecnología biomédica debe asegurarse de que tienen el apoyo y el compromiso de la alta dirección para aumentar las posibilidades de cambio positivo como resultado del análisis. Puede ser útil compartir los informes de RCA de otras investigaciones, como la RCA de ISMP Canadá, citada en el Estudio de Caso 4, para ilustrar la posible salida y el impacto. En el caso del incidente con fluorouracil descrito anteriormente, el Oficial Médico Jefe de la organización tomó medidas inmediatas declarando la tragedia como un fallo de los sistemas, pidiéndole disculpas a la familia y pidiendo que ISMP Canadá llevara a cabo una RCA formal. En este caso, la alta gerencia era muy consciente de la importancia de gestionar el riesgo a nivel de sistemas, más que a nivel de persona.

El RCA ISMP Canadá [94] del incidente con fluorouracilo es un excelente ejemplo de cómo llevar a cabo una RCA. Si bien ISMP Canadá no se refiere a él como un HFRCA, se pidió a un especialista en factores humanos que participara en el equipo RCA del ISMP de Canadá, y realizó varios métodos de HF cubiertos en este libro incluyendo Observaciones (Capítulo 4), Entrevistas (Capítulo 5) y Pruebas de Usabilidad (Capítulo 8). Por consiguiente, el informe incluía una descripción de muchos problemas de factores humanos que se consideró que contribuyeron a las fallos de los sistemas identificados.

218

Sección 13.1.1. Determinar si se requiere HFRCA

Para determinar si es apropiado llevar a cabo una RCA en este caso (es decir, hay problemas de sistemas que deben ser identificados y tratados) el Árbol de Decisión de Incidentes (Figura 26). Es claro en este caso que la realización de un HFRCA es apropiada porque: la enfermera no tenía la intención de causar daño, no había evidencia de mala salud o abuso de sustancias, la enfermera no parece haberse salido de los protocolos acordados o procedimientos seguros, y otros en una situación similar podrían cometer el mismo error. En consecuencia, este evento centinela es un fallo de sistemas en lugar de un problema centrado en la persona y, por lo tanto, requiere un análisis de los riesgos en el sistema para identificar estrategias de mitigación.

Sección 13.1.2. Artículos seguros

Con base en la descripción del caso, los ítems considerados importantes para asegurar fueron:

• La bomba de infusión ambulatoria

• La bolsa de quimioterapia

• Los juegos de mangueras utilizados

• Todas las etiquetas de medicamentos

• El pedido de medicamentos

• Los registros del paciente

• Cualquier nota o documento utilizado para el cálculo

Después de asegurar estos artículos, se tomaron fotografías, y se registraron números de lote, números de serie y fechas de caducidad. Los registros de la bomba se guardaron para futuras revisiones.

Sección 13.1.3. Establecer el equipo

Si un equipo interno de un centro de salud realiza un HFRCA, debe incluir un farmacéutico, una o más enfermeras de oncología, un oncólogo, un administrador de riesgos, un profesional en tecnología biomédica y alguien con experiencia en factores humanos (podría ser el profesional de tecnología biomédica). El equipo debe ser reunido a petición de un administrador senior del hospital que también recibirá informes sobre las actividades del equipo.

En el caso de la RCA llevada a cabo por ISMP Canadá, el equipo estaba formado por cinco profesionales de la salud: tres farmacéuticos con experiencia en seguridad de medicamentos; Una enfermera de oncología, y un médico que también fue un ingeniero de factores humanos.

Un representante de la gerencia de alto nivel de la institución de salud sería una excelente adición al equipo. En el caso de este incidente, el Oficial Médico Jefe apoyó plenamente la finalización de este RCA. El apoyo y la toma de conciencia de las actividades

219

de RCA por parte de los altos directivos es esencial para lograr cambios positivos en la organización de la salud después de un evento centinela.

Sección 13.1.4. Desarrollar una comprensión inicial del incidente

El entendimiento inicial del incidente descrito en el RCA de ISMP Canadá [52] como sigue:

"Una mujer de 40 años murió la semana pasada después de que por error recibió una sobredosis letal de un fármaco de quimioterapia estándar durante el tratamiento en el Instituto de Cáncer XXXX. En lugar de recibir el fármaco intravenoso continuamente durante cuatro días, la mujer recibió la dosis durante cuatro horas el 31 de julio, de una bomba que había sido programada por error. Ella murió el 22 de agosto en el Hospital de la Universidad XXXX de causas complejas, incluyendo un fallo de múltiples órganos, así como sangrado interno generalizado ".

De: XXXX. No podemos eliminar el error humano. XXXX Journal, jueves, 31 de agosto de 2006.

Para ayudar a crear esta sucinta declaración, se creó un diagrama de flujo del proceso para apoyar el desarrollo de la comprensión inicial del incidente (Figura 43). La información utilizada para crear este tipo de diagrama de flujo del proceso suele generarse mediante la realización de observaciones de los entornos de trabajo responsables de todas las tareas relacionadas con el pedido, la preparación y la administración de la quimioterapia intravenosa ambulatoria y la realización de entrevistas con el personal sobre lo ocurrido el día del incidente. La realización de entrevistas después de un incidente puede ser difícil, tanto para el entrevistador como para los entrevistados. Debe prestarse mucha atención a quién conduce las entrevistas, dónde se realizan las entrevistas, las preguntas específicas que se hacen y cómo se sitúa la entrevista al entrevistado.

220

Figura 43. Diagrama de flujo del proceso basado en la comprensión inicial del incidente por el equipo

La creación de este diagrama fue sólo el primer paso para comprender el incidente. Una vez creado, se mejoró iterativamente a través de entrevistas posteriores, un examen del entorno físico, pruebas de usabilidad y una búsqueda de información sobre otros incidentes similares.

En el caso de la RCA llevada a cabo por ISMP Canadá, la comprensión inicial del incidente fue informada por:

• Entrevistas con:

Los miembros del equipo ejecutivo corporativo

Líderes senior

Administradores de Farmacia

Miembros internos del equipo de revisión de incidentes críticos

221

Personal de enfermería y personal médico directamente involucrado en el

incidente

Enfermería y personal médico indirectamente involucrado en el incidente

Personal de enfermería y médicos con conocimientos sobre el proceso típico

de atención

Personal de primera línea

Gerente de ingeniería biomédica

Personal médico de la Unidad de Cuidados Intensivos donde el paciente fue

trasladado tras el incidente

Personal de la residencia del paciente en la comunidad, donde la paciente

había permanecido durante la porción ambulatoria de su tratamiento de

quimioterapia

Un representante del Consejo Provincial de Calidad de la Salud, quien también

realizó una revisión externa del incidente

• Un examen del entorno físico donde ocurrió el incidente

• Observaciones de procesos de trabajo típicos en la Clínica Médica, Área de Tratamiento y Farmacia

• Una prueba de usabilidad de las tareas asociadas con la configuración y programación de la bomba de infusión ambulatoria.

• Búsqueda de información sobre incidentes similares que puedan haber ocurrido a nivel nacional o internacional.

Además de incorporar la información de estos ejercicios de recolección de datos, se incluyó otra información contextual en el diagrama de flujo del proceso, como notas sobre artefactos, tiempo y una comparación de los flujos de trabajo reales, típicos y esperados. (Figura 44). En este caso, uno de los muchos factores identificados como contribuyendo al incidente fue un paso perdido en el cálculo, que resultó en la programación de una tasa de suministro de medicamentos que fue 24 veces demasiado rápida. La Figura 44 muestra este paso de cálculo faltante en el diagrama, pero no lo relaciona con los eventos reales. Los datos de tiempo indicados en el diagrama de flujo del proceso en la Figura 44 no son precisos, y se han incluido sólo con fines ilustrativos.

222

Figura 44. Diagrama de flujo de proceso actualizado basado en datos recolectados a través de entrevistas, observaciones, pruebas de usabilidad y búsquedas de información.

Además de un diagrama de flujo de proceso, una descripción fáctica de los acontecimientos que conducen al incidente entonces se debe crear. Estas descripciones son útiles para ayudar a pensar sistemáticamente en los posibles modos de falla en todo el flujo de trabajo. La siguiente lista contiene un resumen abreviado de los acontecimientos que

223

condujeron al acontecimiento adverso, con un resumen más completo disponible en el informe del ISMP RCA [94].

• El paciente recibió su pre-hidratación, pre-medicamentos, cisplatino y post-hidratación según el protocolo prescrito típico.

• Después de la infusión post-hidratación, la enfermera # 1 calculó la tasa de administración de medicación necesaria para la infusión de fluorouracilo del paciente. Para ello, utilizó la dosis ordenada durante cuatro días (5,250 mg), la duración total de la infusión (4 días) y la concentración final (45,57 mg / ml). Se calculó una tasa de 28,8 ml / h, y se observó que coincidía con un número impreso en la etiqueta de fármaco. El cálculo se realizó utilizando una calculadora disponible en una computadora.

La enfermera # 1 ingresó la tasa de 28,8 mL / h en la bomba de infusión

ambulatoria.

La enfermera # 1 solicitó una segunda comprobación para verificar la tasa

correctamente calculada de entrega de fármacos y la programación de la bomba.

La enfermera # 2 llegó a hacer el cheque, pero no pudo encontrar una calculadora,

por lo que hizo el cálculo mentalmente y en papel. La enfermera # 2 confirmó el

cálculo y la programación de la bomba antes de bloquear la bomba.

Las enfermeras # 1 y # 2 firmaron el registro de administración de medicamentos

manuscritas, documentando la dosis total de fluorouracilo como 5,250 mg.

La enfermera # 1 firmó electrónicamente la dosis total en la computadora.

La enfermera # 1 inició la infusión, revisó la funcionalidad de la bomba con el

paciente y le indicó que regresara al centro oncológico en 4 días.

Alrededor de cuatro horas después de que el paciente salió del centro de cáncer,

la bomba comenzó a sonar porque la bolsa de fluorouracilo estaba vacía.

El paciente se puso en contacto con el centro de cáncer y más tarde regresó al

centro de cáncer, donde el Supervisor de Enfermería de turno de noche

desconectó la bomba y limpió la línea del paciente.

El Supervisor de Enfermería se puso en contacto con el médico de guardia, quien

aconsejó que no se podía hacer nada. El Supervisor de Enfermería completó un

informe de incidente de papel y lo envió, con la bomba, a la Clínica de Tratamiento

de Quimioterapia.

A la mañana siguiente, el Gerente de la Unidad y la Enfermera # 1 revisaron el

historial de la bomba y verificaron que la bomba había sido programada a una

velocidad incorrecta. La bomba debería haber sido programada a una velocidad

de 1,2mL / h, pero fue programada a 28,8mL / h - una tasa que fue 24 veces mayor

que la prevista.

224

Sección 13.1.5. Identificar factores contribuyentes

La descripción fáctica de los acontecimientos pone de relieve que varios factores contribuyentes a través del sistema llevaron a la ocurrencia de este incidente. El marco de factores humanos adaptado del Modelo de Queso Suizo de Reason y la Escala Human-tech de Vicente (Sección 10.6.5.1) es útil para identificar y documentar los factores que contribuyen a través de los niveles del sistema. La ilustración del queso suizo / tecnología humana para este incidente se incluye en la figura 45.

Figura 45. Usando el modelo de Queso Suizo de Reason y la escala de Human-tech de Vicente para identificar los factores que contribuyen a un evento centinela.

Además, la Herramienta del Plan de Acción de la Comisión Conjunta de RCA ayuda a identificar sistemáticamente factores contribuyentes haciendo una serie de preguntas. Un breve pasaje de las preguntas de análisis de la Herramienta del Plan de Acción de la Comisión Conjunta de la RCA que se utilizaron para ayudar a identificar otros factores contribuyentes se incluyen a continuación en la Tabla 28.

225

Tabla 28. Extracto de las preguntas de análisis de la Herramienta del Plan de Acción de la Comisión Conjunta para el incidente con fluorouracilo

Pregunta de análisis Descripción basada en el incidente 2 ¿Hubo alguna etapa en el

proceso que no ocurrió como se esperaba?

La enfermera # 2 buscó una calculadora para hacer su cálculo, pero no pudo encontrar una ...

3 ¿Qué factores humanos fueron relevantes para el resultado?

Sesgo de confirmación: la información sobre la tasa por hora y la tasa por 24 horas estaba disponible en la etiqueta, y se correspondía con lo que las dos enfermeras calculado ...

…

Otras herramientas que son útiles para analizar y documentar factores contribuyentes incluyen Un diagrama de Ishikawa, un diagrama de árbol o un diagrama de constelación (Sección 10.6.5.2).

En este caso, el equipo de RCA de Canadá de ISMP también creó una serie de declaraciones causales para resumir los factores contribuyentes que condujeron al incidente. Una selección de los factores más críticos que contribuyeron a (1) el error de cálculo, (2) la falsa confirmación de la información en la etiqueta y (3) la bomba que se programa de acuerdo con el error de cálculo, se incluyen aquí.

(1) Factores que contribuyen al error de cálculo

Las enfermeras estaban acostumbradas a realizar cálculos complejos que

implicaban múltiples dimensiones, aunque la información estuviera disponible en

la etiqueta del medicamento. Las enfermeras de esta institución hicieron este

cálculo como un doble control para detectar cualquier problema que pudiera

haber sido introducido previamente.

La enfermera # 1 nunca había administrado fluorouracil de esta manera antes y

por lo tanto no sospechaba del valor calculado; esta fue la primera vez que la

enfermera había administrado este protocolo.

La tasa calculada de 28,8 ml no fue inusual para otras infusiones intravenosas

administradas en la clínica de tratamiento de quimioterapia.

La enfermera # 1 no verificó la tasa calculada con una aproximación mental (por

ejemplo, si el volumen total en la bolsa era de 130 ml y la infusión se administrase

a una velocidad de aproximadamente 30 ml / h, la infusión sólo duraría

aproximadamente 4 horas en lugar de las 96 horas previstas).

226

(2) Factores que contribuyen a una falsa confirmación del error de cálculo

La etiqueta del medicamento (Figura 46) contenía información sobre dos

flujos diferentes, incluyendo un flujo por hora y un flujo por 24 horas,

aumentando la oportunidad de una falsa confirmación de la tasa de cálculo

errónea.

Las bombas de infusión ambulatoria usadas previamente en la institución

fueron programadas en ml / 24 h.

Figura 46. Etiqueta de medicación para la infusión de fluorouracilo que contiene dos flunos diferentes

El proceso de doble verificación no fue estandarizado para apoyar un chequeo

independiente por parte de la enfermera # 2, y no hubo ninguna lista de verificación ni

documentación requerida para apoyar el cálculo.

El proceso de doble verificación no era realmente independiente con la documentación

de cálculos matemáticos independientes.

La enfermera # 2 no verificó la tasa calculada con una aproximación mental. (Por

ejemplo, si el volumen total en la bolsa era de 130 ml, y la infusión se administra a una

velocidad de aproximadamente 30 ml / h, la infusión sólo duraría aproximadamente 4

horas en lugar de las 96 horas previstas).

No había calculadora fácilmente disponible para la enfermera # 2, por lo que el cálculo

se hizo en un trozo de papel.

El formato de la etiqueta del medicamento reflejaba la interpretación de la farmacia de

los requisitos legales y las pautas profesionales para el etiquetado de los medicamentos.

Los principios de los factores humanos no fueron tenidos en cuenta para asegurar que el

contenido reflejara los requerimientos de programación de la bomba y que se

incorporaran otros factores, tales como tamaño de fuente óptimo, estilo, uso apropiado

del espacio en blanco, etc.

227

(3) Factores que contribuyen a la incapacidad de la bomba para detectar el error de cálculo

La bomba utilizada en el centro de cáncer no tenía salvaguardias incorporadas

para evitar que los usuarios programen una tasa que exceda un valor máximo

especificado para un medicamento en particular. Esto ocurria con todas las

bombas de infusión ambulatorias electrónicas disponibles en el mercado en ese

momento.

Sección 13.1.6. Desarrollar estrategias de mitigación

Una vez identificados los factores contribuyentes, se deben identificar estrategias de mitigación para abordar esos factores. No existe un enfoque único para el desarrollo de estrategias de mitigación y a menudo se trata de un proceso iterativo, que requiere una cuidadosa consideración de los recursos, factibilidad, rendición de cuentas y, lo que es más importante, eficacia. La Sección 10.6.6 describe varios enfoques para desarrollar estrategias de mitigación y peligros potenciales asociados con esta tarea.

Se formularon varias recomendaciones para abordar los factores contribuyentes identificados a través del HFRCA. Para obtener una lista completa de las recomendaciones identificadas por el ISMP de Canadá, véase ISCA Canadá RCA [69]. Una de esas recomendaciones era que en ausencia de la tecnología de "bombas inteligentes" para bombas de infusión ambulatorias, deberían establecerse otras salvaguardas para asegurar que los parámetros de programación estuvieran dentro de un rango seguro para los medicamentos de alto riesgo. Como ninguna bomba electrónica en el mercado tenía esta capacidad en ese momento, otra opción era migrar al uso de bombas elastoméricas, en lugar de electrónicas. Cuando se consideró esta solución en el contexto de la Jerarquía de Eficacia (Capítulo 3), se determinó que era una solución centrada en los sistemas, y probablemente sería más eficaz que algunas de las otras soluciones centradas en la persona que el equipo había identificado. Resultó, sin embargo, ser menos de una solución a prueba de fallos de lo previsto, como se discute en el caso de estudio de la FMEA en la siguiente sección.

En una RCA típica, se captura una lista de elementos de acción de RCA priorizados (Tabla 28) y el progreso se monitorea usando una hoja de cálculo que describe las acciones de seguimiento y sincronización necesarias (Tabla 29).

Tabla 29. Extracto de la lista priorizada de acciones de la HFRCA

Acción recomendada (categoría)

Riesgo (evaluación de la gravedad)

Jerarquía de Eficacia (alto, medio, bajo apalancamiento)

Predictores de Éxito (alineación, mecanismos existentes, ganancias rápidas)

Nivel del sistema objetivo

Evidencia Disponible?

Qué Tipo?

Confirmar Validez, Factibilidad

Orden de prioridad o marco de tiempo

Migración de Bombas de Infusión electrónicas a Bombas de Infusión elastoméricas

Medio Alto El proyecto reciente de adquisición de bombas en otra unidad podría utilizarse como base para la evaluación

En toda la Unidad en lugar de en toda la organización

Pocas evidencias encontradas

Hablar con otros hospitales que usen elastómericas

Intermedio

228

Tabla 30. Extracto de las acciones de seguimiento y calendario para HFRCA

#

Recomendación Fuente y #

ID

Fecha de ingreso

Estado de progreso

Marco de tiempo (fecha final)

Area Objetivo

Nivel de Riesgo

Responsable Individual

1 Migración de Bombas electrónicas a Bombas elastoméricas

1A 09/09/06 03/01/07 Área de Tratamiento de Quimioterapia

Medio Peter

Se crea un informe para resumir el proceso, los hallazgos y los elementos de acción

derivados del HFRCA. El informe final de ISCA Canadá RCA [94] es un excelente recurso que contiene más detalles.

Sección 13.2. Mejora proactiva de sistemas después de un incidente (HFFMEA)

Tras un análisis retrospectivo como un HFRCA, puede ser beneficioso realizar un análisis prospectivo utilizando HFFMEA. Cuando se aplica una técnica prospectiva después de un análisis retrospectivo, se presenta la oportunidad de identificar los riesgos generales, no directamente involucrados en el incidente. Además, un método de análisis prospectivo como HFFMEA puede aplicarse después de un HFRCA para examinar la posibilidad de que se introduzcan nuevos riesgos en el sistema como resultado de cambios planeados y estrategias de mitigación. El caso de estudio 4 amplía el caso de estudio 3 y se usará para ilustrar cómo el profesional de la tecnología biomédica puede usar HFFMEA para realizar un análisis de riesgo prospectivo.

Caso de estudio 4. Identificación de los riesgos asociados con las bombas de infusión ambulatorias elastoméricas

Implantación de Bombas de Infusión Ambulatorias Elastoméricas

Después del incidente descrito en el Caso de Estudio 3 (Sobredosis de Quimioterapia), se realizó un análisis retrospectivo usando HFRCA (Capítulo 10). Una de las causas raíz identificadas a través del análisis fue que las bombas de infusión ambulatorias electrónicas en uso en el momento del incidente no tenían salvaguardias incorporadas para evitar errores de programación. Con base en este problema, se formuló una recomendación de que la organización sanitaria debería comenzar a utilizar bombas con salvaguardias integradas para evitar errores de la programación.

En el momento del incidente, no había bombas de infusión ambulatorias electrónicas con salvaguardias incorporadas disponibles en el mercado. En consecuencia, la organización sanitaria consideró otras opciones, como las bombas de elastómeros (Figura 47). A diferencia de las bombas electrónicas, las bombas elastoméricas son mecánicas y no requieren ninguna programación de la bomba. Sin embargo, antes de pasar de las bombas de infusión ambulatorias electrónicas a elastoméricas, la organización sanitaria quería entender qué riesgos se asociaban con el uso de estos dispositivos, por lo que un HFFMEA se llevará a cabo en la organización de la salud.

229

Figura 47. Una bomba de infusión ambulatoria elastomérica

Sección 13.2.1. Seleccione un Proceso

El proceso elegido para este HFFMEA particular fue: administrando quimioterapia usando una bomba de infusión ambulante elastomérica. Este proceso se eligió porque a partir del incidente con fluorouracilo se sabía que las bombas de infusión ambulatorias electrónicas en uso en ese momento no contenían ninguna protección incorporada para asegurar que los parámetros introducidos para la programación de bombas caían dentro de rangos aceptables. La razón por la que la institución estaba considerando cambiar a una bomba elastomérica fue para evitar que estos tipos de errores de programación de la bomba ocurrieran cuando la quimioterapia fuera configurada y administrada usando la bomba.

En consecuencia, el punto de partida para el proceso elegido fue: cuando la enfermera recibió la bomba llena de quimioterapia de la farmacia, y el punto final del proceso elegido fue: cuando el paciente dejó la silla de tratamiento de quimioterapia.

Para mantener el análisis enfocado y el alcance manejable, se definieron los siguientes criterios de inclusión y exclusión (Tabla 31):

230

Tabla 31. Criterios de inclusión y exclusión para definir el alcance del proceso

Por lo tanto, el objetivo del proceso era incluir a los pacientes adultos que reciben tratamiento de quimioterapia en la clínica de tratamiento ambulatorio del centro de cáncer, desde el momento en que la enfermera recibe la mezcla de quimioterapia y la bomba de infusión ambulatoria elastomérica de la farmacia, hasta el punto en que el paciente abandona la silla de tratamiento con la infusión funcionando.

Criterios de inclusión y exclusión

Población de pacientes

Inclusiones: Pacientes adultos que reciben quimioterapia

Exclusiones: Pacientes adultos que no reciben quimioterapia, pacientes pediátricos, ensayos clínicos, pacientes y otros casos especiales

Ubicación / Medio Ambiente:

Inclusiones: Clínica de tratamiento ambulatorio del centro de cáncer

Exclusiones: áreas de tratamiento para pacientes hospitalizados, farmacia, clínicas médicas, casa comunitaria

Miembros del Personal

Inclusiones: Enfermeras de quimioterapia que trabajan en la clínica de tratamiento ambulatorio

Exclusiones: Enfermeras de quimioterapia que no trabajan en la clínica de tratamiento ambulatorio, farmacéuticos, médicos / oncólogos, trabajadores comunitarios de la salud, trabajadores de atención domiciliaria

Tareas:

Inclusiones: Recibir la bomba elastomérica llena de farmacia, verificar los cinco parámetros básicos, conectar la bomba al paciente, iniciar la infusión, comprobar que la bomba está infundiendo

Exclusiones: Ordenar quimioterapia, el control de la orden, recolectar suministros para cumplir la orden de quimioterapia, preparar la orden de quimioterapia, comprobar la mezcla de quimioterapia

Equipo:

Inclusiones: Bombas de infusión ambulatorias elastoméricas y tubos / suministros asociados

Exclusiones: Bombas de infusión de gran volumen, bombas de infusión ambulatorias electrónicas

231

Sección 13.2.2. Ensamble un equipo

Aunque el alcance del proceso sólo incluía a enfermeras de quimioterapia y los procesos contenidos en la clínica de tratamiento de quimioterapia, era esencial que las personas fuera de este alcance del proceso se fueran incluidas como parte del equipo HFFMEA.

Para completar este HFFMEA, los siguientes miembros del equipo fueron elegidos y reclutados:

Grupo de trabajo:

• Enfermera de quimioterapia de primera línea

• Profesional de tecnología biomédica

• Especialista en factores humanos

Equipo Asesor:

• Responsable de enfermería para el tratamiento de quimioterapia ambulatoria

• Una segunda enfermera de quimioterapia de primera línea

• Farmacéutico en oncología

• Técnico en farmacología

• Oncólogo

• Enfermera clínica

• Empleado

• Administrador de riesgos

• Director de enfermería de centro de cáncer

232

Sección 13.2.3. Documentar el proceso

Se creó un diagrama de flujo de proceso inicial basado en una comprensión de las tareas que se requerirían para administrar quimioterapia a un paciente adulto usando una bomba de infusión ambulatoria elastomérica (Figura 48).

Reunión de equipo # 1:

Asistentes: equipos de trabajo y asesoramiento

Propósito: conocerse; Revisar el alcance del proceso

Fecha: 2 de mayo de 2007

Tiempo: 12: 00-14: 00

Notas de la reunión:

-Introducciones

-Se decidió sobre las responsabilidades, incluyendo: líder de equipo (profesional de tecnología biomédica), secretaria (enfermera de quimioterapia de primera línea) y facilitador (experto en factores humanos)

-Explicó la diferencia entre el grupo de trabajo y los grupos asesores y estableció expectativas para la frecuencia de las reuniones para el grupo asesor (aproximadamente 7 reuniones de duración variada durante el curso del análisis)

- Ofrece una visión general del alcance del proceso planificado, los puntos de inicio / final y los criterios de inclusión y exclusión

-Tenía una discusión de grupo sobre si el alcance debe ser ampliado para incluir la farmacia; Decidió mantener el mismo por ahora, pero revisar esto en la próxima reunión una vez que el equipo de trabajo ha realizado observaciones y creado un borrador del diagrama de flujo del proceso

233

Figura 48. Diagrama de flujo del proceso inicial para administrar quimioterapia a un paciente adulto con una bomba de infusión ambulatoria elastomérica

Después de crear el diagrama de flujo del proceso inicial, quedaron varias preguntas y áreas de incertidumbre. Los miembros del equipo de trabajo plantearon preguntas sobre cómo controlar la tasa de suministro de la medicación, qué tipo de tubo utilizar y si había consideraciones para las enfermeras sobre la bomba elastomérica. Dado que estos dispositivos no se utilizaban actualmente en la organización sanitaria, el equipo de trabajo se puso en contacto con el proveedor para obtener más información sobre los dispositivos. El proveedor acordó proporcionar muestras de la bomba elastomérica a la organización de atención médica para que pudieran determinar mejor cómo podrían encajar con el flujo de trabajo interno.

El equipo de trabajo también decidió ponerse en contacto con otra organización local que estaba utilizando las bombas elastómericas para ver si podían ir y observar al personal, para ver cómo las bombas encajan en su flujo de trabajo. El equipo de trabajo planeó una visita a esta institución y aprendió a través de observaciones y entrevistas a las enfermeras que la tasa de flujo de la bomba parecía depender de una serie de factores físicos incluyendo la temperatura del paciente, la diferencia de altura entre la bomba y el puerto de infusión, y el tamaño del catéter del paciente. También aprendieron que había que comprar y almacenar varios modelos de bomba de infusión ambulante elastomérica porque cada modelo de bomba suministraba medicación al paciente a una velocidad de flujo diferente.

234

Sobre la base de esta información, el equipo de trabajo decidió programar una segunda visita a la institución local para saber cómo se almacenaban las bombas y cómo la farmacia se aseguraba de que el modelo de bomba elastomérica adecuado se eligió para la quimioterapia de un paciente en particular.

Durante esta segunda visita, el equipo de trabajo aprendió a través de observaciones y entrevistas en la farmacia que el almacenamiento y la selección de la bomba eran a veces desafiantes porque había muchos modelos que parecían similares, con las únicas diferencias siendo una pequeña etiqueta impresa en el dispositivo y plástico de diferente color parte superior. Un farmacéutico también mencionó que el caudal indicado en el lado de la bomba podría verse afectado dependiendo del diluyente que fue utilizado por el técnico de farmacia al mezclar la quimioterapia de un paciente.

El equipo de trabajo actualizó el diagrama de flujo inicial del proceso basado en la información aprendida a través de observaciones y entrevistas (Figura 49). A través de las visitas al campo, también resultó evidente para el equipo que sería importante ampliar el alcance del proceso analizado para incluir: (1) las tareas en farmacia relacionadas con la selección de la bomba adecuada, y (2) la mezcla con el diluyente correcto para asegurar que la quimioterapia se suministra al paciente a la velocidad deseada.

235

Figura 49. Diagrama de flujo de proceso actualizado basado en la información aprendida a través de observaciones y entrevistas en el campo

236

Reunión de equipo # 2:

Asistentes: equipos de trabajo y asesores

Objetivo: revisar el diagrama de flujo del proceso

Fecha: 25 de mayo de 2007

Hora: 8: 00-12: 00

Notas de la reunión:

-Se pidió a los miembros del equipo que se sirvieran café y aperitivos

-Verificado que todos los miembros del equipo recibieron una copia del diagrama de flujo de proceso actualizado para revisión

- Equipo de asesoramiento actualizado sobre lo que el equipo de trabajo ha estado haciendo desde la última reunión. El equipo de trabajo creó un diagrama de flujo de proceso inicial, se puso en contacto con el fabricante de la bomba de infusión ambulatoria elastomérica para obtener más información y muestras, y se contactó con otra institución local utilizando bombas elastoméricas. El equipo de trabajo realizó dos visitas de campo donde se realizaron observaciones y entrevistas. Se aprendió que varios factores afectan el caudal de estas bombas y que muchos modelos de bombas necesitan ser comprados y almacenados, ya que cada modelo suministra medicación a un ritmo diferente.

-Revisión del diagrama de flujo del proceso actualizado con el equipo asesor

-Discutió y llegó a un consenso de que el alcance del proceso debería ampliarse para incluir la farmacia basada en observaciones y entrevistas

-Revisión de la membresía del equipo de trabajo y asesoramiento para asegurar que la experiencia en farmacia se tuviera en cuenta; ya que el farmacéutico y el técnico de farmacia ya forman parte del equipo, se acordó que no se requieren nuevos miembros en este punto

-Feedback adquirido del equipo asesor sobre los pasos actualizados del diagrama de flujo del proceso; se acordaron varias modificaciones menores basadas en la contribución del experto de la materia

- Próximos pasos: el equipo de trabajo actualizará el diagrama de flujo del proceso basado en la retroalimentación de la reunión de hoy y volverá a circular dentro de dos semanas para su revisión y aprobación por miembros del equipo asesor.

237

Sección 13.2.4. Identificar los modos de falla y efectos

El equipo de trabajo convirtió el diagrama de flujo del proceso final aprobado por el equipo asesor en un formato de hoja de cálculo, una parte de la cual se muestra en la Tabla 32.

Tabla 32. Parte de la hoja de cálculo creada con base en el diagrama de flujo del proceso aprobado

Tarea # Modo de Falla (MF) Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Conseguir los suministros de la mezcla

1.1 Seleccionar la droga

1.2 Seleccionar el diluyente

1.3 Seleccionar bomba elastomérica

1.4 Seleccionar suministros

2.0 Enviar suministros al cuarto limpio

3.0 Farmacia revisa suministros

4.0 Llevar suministos al gabinete de seguridad biológica

5.0 Preparar mezcla de quimio

6.0 Farmacia revisa la mezcla

7.0 Farmacia documenta y firma

8.0 Entregar mezcla a enfermería

9.0 Recibir de farmacia la mezcla de quimio y la bomba

… ….

… ….

… ….

238

El equipo de trabajo se reunió entonces para identificar sistemáticamente modos de falla y efectos para cada paso de tarea y sub-paso como se muestra en la Tabla 33.

Tabla 33. Parte de la hoja de cálculo que muestra los modos de falla y los efectos basados en el diagrama de flujo del proceso

Después de elaborar una lista preliminar de modos y efectos de falla, el equipo de trabajo desarrolló escalas de calificación para su revisión en la próxima reunión del equipo asesor. La severidad y las escalas de calificación de probabilidad se muestran en la Tabla 34 y Tabla 35, respectivamente.

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Conseguir los suministros de la mezcla

1 Suministros incorrectos

Mexcla preparada incorrecta

2 Suministros incompletos

Mexcla no es preparada

1.1 Seleccionar la droga 3 Droga errada seleccionada

Paciente recibe droga errada

1.2 Seleccionar el diluyente

4 Diluyente errado seleccionado

Velocidad de infusi’on muy rápida o muy lenta

1.3 Seleccionar bomba elastomérica

5 Elastomérica seleccionada errada

Velocidad de infusi’on muy rápida o muy lenta

6 Elastomérica no seleccionada

Mezcla no es preparada

1.4 Seleccionar suministros

7 Suministros errados seleccionados

Mezcla preparada incorrecta

2.0 Enviar suministros al cuarto limpio

8 Suministros no enviados a cuarto limpio

Mezcla no es preparada

3.0 Farmacia revisa suministros

9 Farmacia no revisa suministros

Paciente recibe la droga errada o un flujo errado

… …. …

… …. …

… …. …

239

Tabla 34. Escala de gravedad desarrollada por el equipo de trabajo para este HFFMEA

Tabla 35. Escala de calificación de probabilidad desarrollada por el equipo de trabajo para este HFFMEA

Probabilidad

Calificación Descripción Definición

1 Remoto Poco probable que ocurra (una vez cada 5-30 años)

2 Poco común Es posible que ocurra (puede ocurrir una vez en 2-5 años)

3 Ocasional Probable que ocurra (puede ocurrir más de una vez en 1-2 años)

4 Frecuente Probable que ocurra (puede ocurrir varias veces durante un año)

240

Sección 13.2.5. Calificar los Efectos del modo de falla y Determinar los modos clave de falla

Utilizando las matrices de puntuación de gravedad y probabilidad acordadas por el equipo asesor, el equipo de trabajo calificó cada modo y efecto de falla (Tabla 36). Siempre que hubo desacuerdos sobre cómo se debe calificar un ítem, se discutió hasta que se llegó a un consenso.

Reunión de equipo # 3:

Asistentes: equipos de trabajo y asesoramiento

Propósito: revisar y ampliar los posibles modos de falla y efectos

Fecha: 15 de junio de 2007

Hora: 8: 00-16: 00

Notas de la reunión:

-Revisión de la agenda incluyendo pausas programadas y almuerzo.

- Los miembros confirmados del equipo recibieron una copia de la hoja de cálculo que contiene los modos de falla y los efectos del diagrama de flujo del proceso aprobado.

-Facilitador condujo al grupo a través de los pasos del proceso y los modos de falla asociados y los efectos fila por fila y pidió opiniones del grupo. El facilitador recordó al grupo que con este tipo de análisis, incluso si un modo de falla parece improbable o no ha ocurrido anteriormente, podría ocurrir y debería incluirse en la hoja de cálculo.

Discusiones en grupo sobre muchos de los modos de fallos listados, con varios nuevos modos de fallos añadidos por el equipo. El secretario documentó esta discusión en tiempo real para que el equipo pudiera ver las ediciones que se realizarán en la hoja de cálculo. Los miembros del equipo presentaron varias causas, pero esto no fue el foco de esta reunión. Así que el secretario los capturó en un archivo separado para su posterior revisión.

- Sugirieron algunos cambios en el diagrama de flujo del proceso aprobado; estos serán realizados por el equipo de trabajo después de la reunión.

-Después de que se revisaron los modos y efectos de fallo, el facilitador comparte las matrices de puntuación de gravedad y probabilidad con el grupo para la discusión. El grupo estuvo de acuerdo en que las matrices de puntuación no necesitaban más modificaciones.

-Pasos siguientes: equipo de trabajo actualizara el diagrama de flujo de procesos y modos de fallo y hojas de cálculo de efectos y enviar ambos documentos al equipo asesor para su revisión.

241

Tabla 36. Parte de la hoja de cálculo que muestra los puntajes asignados para la gravedad y la probabilidad

Tarea # Modo de Falla (MF)

Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Conseguir los suministros de la mezcla

1 Suministros incorrectos

Mezcla preparada incorrecta

3 3

2 Suministros incompletos

Mezcla no es preparada

2 2

1.1 Seleccionar la droga

3 Droga errada seleccionada

Paciente recibe droga errada

4 3

1.2 Seleccionar el diluyente

4 Diluyente errado seleccionado

Velocidad de infusión muy rápida o muy lenta

4 3

1.3 Seleccionar bomba elastomérica

5 Elastomérica seleccionada errada

Velocidad de infusión muy rápida o muy lenta

4 4

6 Elastomérica no seleccionada

Mezcla no es preparada

3 2

1.4 Seleccionar suministros

7 Suministros errados seleccionados

Mezcla preparada incorrecta

3 3

2.0 Enviar suministros al cuarto limpio

8 Suministros no enviados a cuarto limpio

Mezcla no es preparada

2 2

3.0 Farmacia revisa suministros

9 Farmacia no revisa suministros

Paciente recibe la droga errada o un flujo errado

4 3

… …. …

… …. …

… …. …

242

Una vez que el equipo asesor había acordado puntajes de gravedad y probabilidad, el equipo de trabajo se reunió nuevamente y aplicó las Tres Pruebas (Sección 9.5.6.1) para determinar si cada modo de falla era un modo clave de falla (Tabla 37).

Reunión de equipo # 4:

Asistentes: equipos de trabajo y asesoramiento

Objetivo: llegar a un consenso sobre la gravedad y la probabilidad de los modos y efectos de falla

Fecha: 26 de junio de 2007

Hora: 14: 00-17: 00

Notas de la reunión:

-Se invitó a los miembros del equipo a servirse café y muffins

-Los miembros del equipo confirmados recibieron una copia de la hoja de cálculo HFFMEA que contenía puntuaciones de probabilidad y gravedad y copias de las matrices de puntuación de gravedad y probabilidad

-El Facilitador recordó al equipo que pensara acerca de las limitaciones humanas, incluyendo el sesgo cognitivo, y las limitaciones en la memoria y la atención al puntuar la gravedad y la probabilidad de cada modo de falla. El facilitador señaló que el personal tiene las mejores intenciones cuando vienen a trabajar, pero no se puede esperar que sean sobrehumanas.

-El Facilitador trabajó a través de cada modo de falla, comenzando por compartir la asignación de puntuaciones de los equipos de trabajo y luego invitó a la discusión al equipo asesor.

-Los miembros del equipo asesor estuvieron de acuerdo con muchas de las puntuaciones pre-asignadas, sin embargo, algunos cambios fueron solicitados y discutidos por el grupo, con el escriba edición de puntajes en tiempo real.

- El equipo asesor revisó las puntuaciones de los modos y efectos de falla y discutió los umbrales de corte para la puntuación de gravedad y peligro; decidió un umbral de severidad de 3 o más y un umbral de puntaje de riesgo de 8 o más.

243

Tabla 37. Parte de la hoja de cálculo que muestra la determinación de los modos clave de falla

El equipo de trabajo creó una nueva hoja de cálculo que incluía sólo aquellos modos de fallo considerados como los modos clave de fallo. Estos modos de fallo conllevaban un riesgo superior al umbral de riesgo predefinido por el equipo asesor. Éstos se convirtieron en los modos de la fallo que requirieron la consideración adicional en el evento de que la organización de salud decidiera seguir adelante con la implementación de las bombas elastomericas.

Tarea # Modo de Falla (MF) Efecto Calificación Modo de Falla Clave (MFC)

# Descripción # Descripción Severidad

(S)

Probabilidad

(P)

Nivel de

Riesgo

(HS)

S>

+=

3

HS

>=8

Controlada Detectable Debilidad de Punto Simple (SPW)

MFC ¿?

1.0 Conseguir los suministros de la mezcla

1 Suministros incorrectos

Mezcla preparada incorrecta

3 3 9 S S S

2 Suministros incompletos

Mezcla no es preparada

2 2 4 N N N S N

1.1 Seleccionar la droga

3 Droga errada seleccionada

Paciente recibe droga errada

4 3 12 S S S

1.2 Seleccionar el diluyente

4 Diluyente errado seleccionado

Velocidad de infusión muy rápida o muy lenta

4 3 12 S S S

1.3 Seleccionar bomba elastomérica

5 Elastomérica seleccionada errada

Velocidad de infusión muy rápida o muy lenta

4 4 16 S S S

6 Elastomérica no seleccionada

Mezcla no es preparada

3 2 6 S N S

1.4 Seleccionar suministros

7 Suministros errados seleccionados

Mezcla preparada incorrecta

3 3 9 S S S

2.0 Enviar suministros al cuarto limpio

8 Suministros no enviados a cuarto limpio

Mezcla no es preparada

2 2 4 N N N S N

3.0 Farmacia revisa suministros

9 Farmacia no revisa suministros

Paciente recibe la droga errada o un flujo errado

4 3 12 S Y Y

… …. … … … … … … … … … … … …

… …. … … … … … … … … … … … …

244

Sección 13.2.6. Identificar Causas

Para aquellos modos de fallo determinados como modos clave de fallo, el equipo de trabajo se reunió para discutir posibles causas raíz y factores contribuyentes. Las causas que fueron planteadas durante las reuniones de los equipos asesores pasados y fueron registradas por el miembro del equipo de trabajo en el papel de escriba, fueron reexaminadas para determinar si podrían ser factores que contribuyen a cualquiera de los modos clave de fallo. En la Tabla 38 se incluye una selección de los modos clave de fallo y las posibles causas.

Tabla 38. Parte de la hoja de cálculo HFFMEA actualizada que muestra las posibles causas de los modos clave de fallo

Como parte del HFFMEA, el equipo de trabajo tuvo cuidado de pensar más allá de factores como el cumplimiento de protocolos y procedimientos establecidos, y otras causas más centradas en el ser humano. En cambio, el equipo de trabajo se centró en causas a nivel de sistema y factores contribuyentes, sabiendo que sólo cuando se abordaran los factores del sistema se lograrían mejoras significativas en la seguridad del paciente y del personal.

Tarea # Modo de Falla (MF) Efecto Causas Estrategias de Mitigación

# Descripción # Descripción

1.0 Conseguir suministros para la mezcla

1 Suministros errados

Mezcla peparada incorrectamente

No hay un alista de suministros a conseguir

Conseguir suministros en bloque puede llevar a errores

1.1 Seleccionar droga

3 Droga errada seleccionada

Paciente recibe droga errada

Drogas con nombres parecidos (suena similar)

Almacenamiento y organización de drogas

1.2 Seleccione diluyante

4 Diluyente errado seleccionado

Velocidad de infusión muy rápida o muy lenta

El almacenamiento hace posible que se seleccione el diluyente errado

1.3 Seleccione bomba elastomérica

5 Elastomérico seleccionado errado

Velocidad de infusión muy rápida o muy lenta

Las bombas elastoméricas todas se ven iguales

La velocidad de flujo no es aparente en la bomba

Muchos modelos para seleccionar

… … … … … … …

245

Sección 13.2.7. Desarrollar e implementar estrategias de mitigación

Sobre la base de las causas identificadas por el equipo asesor, el equipo de trabajo se reunió y organizó una serie de posibles estrategias de mitigación para abordar problemas del sistema en la raíz de cada modo clave de falla. El equipo de trabajo se refirió a la Jerarquía de Eficacia (Capítulo 3), mientras que el desarrollo de posibles estrategias de mitigación para asegurar soluciones dirigidas a nivel de sistema, en lugar de factores a nivel de persona.

Reunión de equipo # 5:

Asistentes: equipos de trabajo y asesoramiento

Finalidad: finalizar causas raíz para cada modo de fallo de clave

Fecha: 20 de julio de 2007

Hora: 9: 00-12: 00

Notas de la reunión:

-Se invitó a los miembros del equipo a servirse café y galletas/magdalenas

-Los miembros del equipo confirmados recibieron una copia de la hoja de cálculo HFFMEA que contiene las causas

- El facilitador recordó al grupo que no se concentrara en las causas centradas en el ser humano y en no seguir los procedimientos como causas raíz. En su lugar, el grupo debe pensar en las causas del nivel del sistema que contribuyen a los posibles modos de falla.

-El facilitador guió el grupo a través de cada modo clave de fallo y las causas potenciales que habían sido identificadas por el equipo de trabajo. El grupo discutió estas y otras causas potenciales para cada modo clave de fallo. El escriba registró la discusión en tiempo real para que todos los miembros del equipo asesor pudieran seguirla.

- Durante la discusión se identificaron varias causas a nivel de sistema que podrían contribuir a varios modos clave de fallo. Estos tipos de factores que contribuyen pueden ser adecuados para enfocarse cuando se trata de desarrollar estrategias de mitigación pues la corrección incluso sólo uno de estos factores que contribuyen podría tener el potencial de mitigar varios modos clave de fallo.

Próximos pasos: El equipo de trabajo se reunirá para actualizar y refinar la lista de causas basadas en esta reunión. La hoja de cálculo actualizada se distribuirá al equipo asesor en las próximas tres semanas para su revisión y retroalimentación.

246

Si la organización sanitaria decide implementar bombas elastoméricas, en paralelo también desearían considerar la implementación de una serie de estrategias mitigadoras identificadas para prevenir proactivamente cualquier error potencial identificado a través del análisis.

Reunión de equipo # 6:

Asistentes: equipos de trabajo y asesoramiento

Propósito: desarrollar estrategias de mitigación para abordar las causas raíz para cada modo clave de falla

Fecha: 17 de agosto de 2007

Hora: 13: 00-16: 00

Notas de la reunión:

-Se invitó a los miembros del equipo a servirse café y muffins

-Los miembros del equipo confirmados recibieron una copia de la hoja de cálculo de HFFMEA que contiene las causas finalizadas y las ideas preliminares para mitigar las estrategias.

-El facilitador distribuyó copias de la Jerarquía de Eficacia (Capítulo 11) a cada miembro del equipo asesor y describió el modelo para ayudar a asegurar que las recomendaciones generadas fueran más centradas en los sistemas que centradas en la persona.

-Ideas para saber cómo mitigar las causas de raíz para cada modo de falla fueron discutidas por el equipo y la Jerarquía de Eficacia fue referida a lo largo de la discusión.

- El equipo asesor discutió los posibles criterios que podrían utilizarse para destacar aquellas estrategias de mitigación que probablemente sean las más viables. Considerado varios aspectos diferentes tales como (1) cómo eficaz (jerarquía de la eficacia), (2) recursos requeridos, (3) recursos disponibles, el equipo estuvo de acuerdo en que sería preferible implementar menos estrategias de mitigación de alto impacto que muchas estrategias de mitigación de bajo impacto.

- El equipo asesor buscó e identificó posibles áreas de superposición en las que la implementación de una sola recomendación trataría más de una causa.

- El secreario registró ola discusión en tiempo real para que los miembros del equipo puedan verla y seguirla.

-Pasos siguientes: equipo de trabajo para hacer circular la versión mejorada de la hoja de cálculo HFFMEA que contiene ideas sobre estrategias de mitigación

247

Sobre la base de las ideas preliminares para mitigar las estrategias y la discusión durante la Reunión # 6 del equipo, el equipo de trabajo actualizó la hoja de cálculo HFFMEA (Tabla 39) y la distribuyó al equipo asesor para su revisión y retroalimentación.

Tabla 39. Parte de la hoja de cálculo actualizada de HFFMEA que muestra ideas para posibles estrategias de mitigación

Tarea # Modo de Falla (MF) Efecto Causas Estrategias de Mitigación

# Descripción # Descripción

1.0 Conseguir suministros para la mezcla

1 Suministros errados Mezcla peparada incorrectamente

No hay un alista de suministros a conseguir

Usar T.I. para generar lista electrónica basada en protocolos

Conseguir suministros en bloque puede llevar a errores

Cambiar los procesos para que la lista de suministros de un paciente sean recogidos antes de pasar a la mezcla del siguiente paciente

1.1 Seleccionar droga 3 Droga errada seleccionada

Paciente recibe droga errada

Drogas con nombres parecidos (suena similar)

Implementar uso de mezcla de letras mayúsculas y minúsculas (TALLman)

Almacenamiento y organización de drogas

Almacene drogas que se vean o ‘suenen’ parecido lejos una de otra

1.2 Seleccione diluyante 4 Diluyente errado seleccionado

Velocidad de infusión muy rápida o muy lenta

El almacenamiento hace posible que se seleccione el diluyente errado

Almacerne las bolsas de NS y DWS en zonas diferentes de la la antesala

1.3 Seleccione bomba elastomérica

5 Elastomérico seleccionado errado

Velocidad de infusión muy rápida o muy lenta

Las bombas elastoméricas todas se ven iguales

Almacene las bombas de forma que los colores superiores sean visibles

La velocidad de flujo no es aparente en la bomba

Añada etiquetas a los estantes de almacenamiento para que la información de velocidad de flujo sea mas fácil de ver al seleccionar

Contacte al fabricante para vdr si la información de velocidad de flujo puede hacerse más sobresaliente

Muchos modelos para seleccionar

Considere usar marcas según dosis para que solo se requieran agunos pocos modelos

… … … … … … …

248

Reunión de equipo # 7:

Asistentes: equipos de trabajo y asesoramiento

Propósito: priorizar estrategias de mitigación, crear planes de implementación, concluir HFFMEA

Fecha: 31 de agosto de 2007

Hora: 8: 00-12: 00

Notas de la reunión:

- Se invita a los miembros del equipo a servirse café y muffins

- Los miembros confirmados del equipo recibieron una copia de la hoja de cálculo actualizada de HFFMEA que contiene estrategias de mitigación

- El Facilitador recordó al equipo asesor que se refiriera a la Jerarquía de Eficacia durante la discusión y revisó los criterios discutidos durante la reunión anterior para destacar aquellas estrategias mitigantes que probablemente sean las más factibles.

-El facilitador presentó las reflexiones de los grupos de trabajo acerca de qué estrategias de mitigación serían más factibles y tendrían el mayor impacto basándose en los criterios elegidos.

- Se discutió entre los miembros del grupo asesor acerca de los pros y los contras de intentar implementar las estrategias de mitigación propuestas y se abrió el debate para considerar si otras estrategias deberían ser consideradas con más detalle.

- El equipo asesor dio prioridad a las estrategias de mitigación considerando los criterios elegidos para determinar (1) cuán eficaz, (2) los recursos que se podrían requerir y (3) los recursos que probablemente estén disponibles.

-Basado en la larga lista de posibles estrategias de mitigación, el equipo asesor eligió las 10 estrategias prioritarias más importantes y desarrolló un plan de implementación para cada una (Sección 9.6, Qué Hacer con un HFFMEA Completo). En el caso de que la organización sanitaria decida pasar a bombas elastoméricas, cada plan de implementación será asignado a un miembro del personal que analizará plan para que los modos clave de fallo asociados se pueden mitigar antes de causar daño.

-El líder del equipo concluyó la reunión agradeciendo a todos por su participación como parte del equipo asesor de HFFMEA. Aunque el trabajo de implementación continuaría si la organización decidiera seguir adelante con las bombas de elastómero, ésta fue la última reunión oficial del equipo HFFMEA.

249

Después de la reunión final de HFFMEA, el grupo de trabajo se reunió para crear un documento de resumen que describía (1) el proceso HFFMEA seguido, (2) los miembros del equipo en los grupos de trabajo y de asesoramiento, (3) las decisiones clave tomadas, {4] lecciones aprendidas, (5) estrategias de implementación desarrolladas, y (6) un apéndice que contiene los modos clave de falla, sus causas y efectos. Antes de proporcionar el informe a la alta dirección, se compartió con el equipo asesor para obtener información.

El informe fue compartido con la gerencia de la organización sanitaria de manera oportuna para que la información sobre los modos clave de fallo y los posibles medios de mitigar los riesgos asociados con la implementación de las bombas de elastómero se pudieran integrar con el proceso de toma de decisiones de las organizaciones sanitarias. Este recurso proporcionó una visión de los riesgos potenciales asociados con la implementación de bombas elastómericas, lo que podría ser comparado con los riesgos inherentes asociados con el mantenimiento de las bombas de infusión ambulatorias electrónicas descubiertos como parte de la HFRCA. De esta manera, la gerencia pudo tomar una decisión más informada al sopesar el riesgo residual asociado con el mantenimiento de las bombas electrónicas existentes versus la implementación de las nuevas bombas elastoméricas.

250

Recursos de Factores Humanos

HumanEra

Este libro se basa en la experiencia colectiva de los miembros del equipo de HumanEra. HumanEra es un equipo de investigación de factores humanos de salud basado en el Centro de Innovación eHealth Global en Toronto, Canadá, con más de una década de experiencia en la realización de proyectos de investigación aplicada e implementaciones para mejorar la seguridad del sistema de salud. Para contactar o aprender más acerca de HumanEra visite nuestro sitio web en www.HumanEra.ca.

Libros de Factores Humanos

No hay escasez de libros y textos sobre el tema de los factores humanos, sus métodos y aplicaciones específicas a través de dominios individuales, pero los dos libros siguientes proporcionan una excelente introducción sobre el tema y están llenos de ejemplos relevantes.

1. Kim J. Vicente. The human factor: Revolutionizing the way we live with

technology: Vintage Canada; 2004.

2. Steven M. Casey. Set phasers on stun: And other true tales of design, technology,

and human error: Aegean Publishing Co.; 1998.

Eventos/Organizaciones de Factores Humanos

The Human Factors and Ergonomics Society (HFES); www.hfes.org.

Esta organización americana realiza una conferencia anual (produce actas publicadas) y publica las revistas Factores Humanos, Ergonomía en Diseño y la Revista de Ingeniería Cognitiva y Toma de Decisiones. HFES cuenta con un Grupo Técnico de Salud (http://hctg.wordpress.com) y organiza un Simposio anual sobre Factores Humanos y Ergonomía en Salud. HFES también tiene un capítulo europeo.

SIGCHI; www.sigchi.org.

Esta organización internacional realiza una conferencia anual (produce actas publicadas y publica la revista TOCHI (ACM Transactions on Computer- Human Interaction).

The Institute of Ergonomics and Human Factors; http://iehf.org.

Esta organización con sede en el Reino Unido realiza una conferencia anual, acredita a profesionales y tiene un grupo de interés especializado en Salud.

The International Conference on Applied Human Factors and Ergonomics and the

Affiliated Conferences; www.ahfe2014.org.

251

Celebrada simultáneamente como parte de este evento hay una Conferencia Internacional sobre Factores Humanos y Ergonomía en la Salud. AHFE publica los libros editados después de la conferencia con documentos aceptados y revisados por pares.

Documentos de Orientación de Factores Humanos de Salud

1. La FDA ha elaborado un proyecto de documento de orientación para ayudar a la

industria a realizar pruebas de factores humanos apropiadas e identificar las

características del dispositivo que los fabricantes deben optimizar durante todo

el ciclo de vida del producto. Disponible en:

http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedo cuments/ucm259748.htm

2. La Organización Mundial de la Salud ha elaborado un documento que examina

diez áreas temáticas relacionadas con los factores organizativos y humanos que

influyen en la seguridad de los pacientes. Disponible en:

http://www.who.int/patientsafety/research/methods_measures/human_factor s/human_factors_review.pdf?ua=1

3. El grupo de factores humanos clínicos (www.chfg.org) ha influido en el primer

volumen y producido el segundo volumen de un documento titulado

Implementing Human Factors in healthcare.

Volumen 1 (publicado por Patient Safety First) disponible en:

http://www.patientsafetyfirst.nhs.uk/ashx/Asset.ashx?path=/Intervention- support/Human%20Factors%20How-to%20Guide%20v1.2.pdf

Volumen 2 disponible en:

http://www.chfg.org/wp-content/uploads/2013/05/Implementing-human- factors-in-healthcare-How-to-guide-volume-2-FINAL-2013_05_16.pdf

252

Referencias 1. To Err Is Human: Building a Safer Health System: The National Academies Press;

2000.

2. Baker GR, Norton PG, Flintoft V, Blais R, Brown A, Cox J, Etchells E, Ghali WA, Hébert P,

Majumdar SR et al: The Canadian Adverse Events Study: the incidence of adverse

events among hospital patients in Canada. Canadian Medical Association Journal 2004,

170(11):1678-1686.

3. Sari ABA, Sheldon TA, Cracknell A, Turnbull A, Dobson Y, Grant C, Gray W,

Richardson A: Extent, nature and consequences of adverse events: results of a

retrospective casenote review in a large NHS hospital. Quality & Safety in HealthCare

2007, 16(6):434-439.

4. Davis P, Lay-Yee R, Briant R, Ali W, Scott A, Schug S: Adverse events in NewZealand

public hospitals I: occurrence and impact. The New Zealand medical journal 2002,

115(1167):U271.

5. Wilson RM, Harrison BT, Gibberd RW, Hamilton JD: An analysis of the causes ofadverse

events from the Quality in Australian Health Care Study. The MedicalJournal of

Australia 1999, 170(9):411-415.

6. James JT: A New, Evidence-based Estimate of Patient Harms Associated

withHospital Care. Journal of Patient Safety 2013, 9(3):122-128.

7. FDA: Draft Guidance for Industry and Food and Drug Administration Staff -

Applying Human Factors and Usability Engineering to Optimize Medical Device

Design. In.; 2011.

8. American College of Clinical Engineering (ACCE)

[http://www.accenet.org/default.asp?page=about&section=definition]

9. Vicente K: The human factor: Revolutionizing the way we live with technology:

Vintage Canada; 2004.

10. Norman DA: The Design of Everyday Things: Basic Books; 2002.

11. United States. Army Air Forces. Headquarters AMCED: Analysis of Factors

Contributing to 460 "pilot-error" Experiences in Operating Aircraft Controls: Army

Air Forces Headquarters, Air Material Command, Engineering Division; 1947.

12. Wiener EL, Nagel DC: Human factors in aviation: Access Online via Elsevier; 1988.

13. Misumi J, Miller R, Wilpert B: Nuclear safety: A human factors perspective: CRC Press;

1998.

14. Stanton NA: Human factors in nuclear safety: Taylor & Francis; 1996.

15. Carayon P: Human factors in patient safety as an innovation. Applied ergonomics

2010, 41(5):657-665.

253

16. Cooper JB, Newbower RS, Long CD, McPeek B: Preventable Anesthesia Mishaps: A

Study of Human Factors. Anesthesiology 1978, 49(6):399-406.

17. Leape LL: Error in medicine. JAMA-Journal of the American Medical Association-US

Edition 1994, 272(23):1851-1856.

18. Leape LL, Brennan TA, Laird N, Lawthers AG, Localio AR, Barnes BA, Hebert L,

Newhouse JP, Weiler PC, Hiatt H: The nature of adverse events in hospitalized

patients: results of the Harvard Medical Practice Study II. New England Journal of

Medicine 1991, 324(6):377-384.

19. Hollands JG, Wickens CD: Engineering psychology and human performance: Prentice Hall New Jersey; 1999.

20. Weissman JS, Rothschild JM, Bendavid E, Sprivulis P, Cook EF, Evans RS, Kaganova Y, Bender M, David-Kasdan J, Haug P et al: Hospital workload and adverse events. Med Care 2007, 45(5):448-455.

21. Harrison MI, Koppel R, Bar-Lev S: Unintended consequences of information technologies in health care: an interactive sociotechnical analysis. Journal of the American Medical Informatics Association 2007, 14(5):542-549.

22. Jennings BM: Work Stress and Burnout Among Nurses: Role of the Work Environment and Working Conditions. 2008.

23. Flewwelling CJ: No Fault Found Reporting and its Relation to Human Factors Related Design Faults of Medical Devices. 2012.

24. Smith EE, Kosslyn SM: Cognitive Psychology: Mind and Brain: Pearson/Prentice Hall; 2007.

25. Mack A, Rock I: Inattentional Blindness: MIT Press; 1998.

26. Alert IMS: Medication error prevention “tool box”. Retrieved June 1999, 30:2004.

27. McCarney R, Warner J, Iliffe S, van Haselen R, Griffin M, Fisher P: The Hawthorne Effect: a randomised, controlled trial. BMC Med Res Methodol 2007, 7:30.

28. Bailey RW: Performance vs. preference. In: Proceedings of the Human Factors and Ergonomics Society Annual Meeting: 1993. SAGE Publications: 282-286.

29. Crabtree BF, Miller WL: Doing Qualitative Research: SAGE Publications; 1999.

30. Glaser B: The Constant Comparative Method of Qualitative Analysis. Social Problems 1965, 12(4):436-445.

31. Kirwan BE, Ainsworth LK: A guide to task analysis. 1992.

32. Nielsen J: Usability inspection methods. In: Conference Companion on Human Factors in Computing Systems; Boston, Massachusetts, USA. ACM 1994.

33. Shneiderman SB, Plaisant C: Designing the user interface 4 th edition. In.: Pearson Addison Wesley, USA; 2005.

254

34. Zhang J, Johnson TR, Patel VL, Paige DL, Kubose T: Using usability heuristics to evaluate patient safety of medical devices. Journal of Biomedical Informatics 2003, 36:23-30.

35. Nielsen J, Molich R: Heuristic evaluation of user interfaces. In: Proceedings ACM CHI'90 Conf: 1990; Seattle, WA, 1-5 April. ACM: 249-256.

36. Food, Administration D: Draft Guidance for Industry and Food and Drug Administration Staff. Applying Human Factors and Usability Engineering to Optimize Medical Device Design. US Food and Drug Administration, Silver Spring, MD 2011.

37. DeRosier J, Stalhandske E, Bagian JP, Nudell T: Using health care Failure Mode and Effect Analysis: the VA National Center for Patient Safety's prospective risk analysis system. Jt Comm J Qual Improv 2002, 28(5):248-267, 209.

38. Failure Mode And Effects Analysis (FMEA): A Tool to Help Guide Error Prevention Efforts [https://www.ismp.org/tools/FMEA.asp]

39. ISMP Canada Failure Mode and Effects Analysis [http://www.ismp-canada.org/fmea.htm]

40. Institute for Healthcare Improvement: Failure Mode and Effects Analysis (FMEA) Tool [http://app.ihi.org/Workspace/tools/fmea/]

41. 2014 Hospital Accreditation Standards. Oakbrook Terrace, Illinois: Joint Commission; 2013.

42. Required Organizational Practices 2012. In., vol. 2013. Ottawa: Accreditation Canada; 2012.

43. Safety VNCfP: The basics of Healthcare Failure Mode and Effect Analysis. In., vol. 2013: Veterans Affairs National Center for Patient Safety; 2001.

44. Commission J: Sentinel Events. Comprehensive Accreditation Manual for Office- Based Surgery Practices 2011:SE-1 to SE-18.

45. Smetzer J, Baker C, Byrne FD, Cohen MR: Shaping systems for better behavioral choices: lessons learned from a fatal medication error. Joint Commission Journal on Quality and Patient Safety 2010, 36(4):152.

46. Cohen MR: An Injustice Has Been Done: Jaile Time for an Error. Patient Safety and Quality Healthcare 2009(September/October 2009):6-7.

47. Wu AW: Medical error: the second victim. BMJ 2000, 320(7237):726-727.

48. Anderson P, Townsend T: Medication errors: Don’t let them happen to you. American Nurse Today 2010, 5(3):23-27.

49. Clancy CM: Alleviating "second victim" syndrome: how we should handle patient harm. J Nurs Care Qual 2012, 27(1):1-5.

255

50. Framework for Conducting a Root Cause Analysis and Action Plan | Joint Commission [http://www.jointcommission.org/Framework_for_Conducting_a_Root_Cause_Analy sis_and_Action_Plan/]

51. Root Cause Analysis - VA National Center for Patient Safety [http://www.patientsafety.va.gov/media/rca.asp]

52. ISMP Canada - Root Cause Analysis [https://www.ismp-canada.org/rca.htm]

53. Canadian Incident Analysis Framework [http://www.patientsafetyinstitute.ca/English/toolsResources/IncidentAnalysis/D ocuments/Canadian%20Incident%20Analysis%20Framework.PDF]

54. Patient Safety - Root Cause Analysis toolkit | conditions of use [http://www.nrls.npsa.nhs.uk/resources/rca-conditions/]

55. Meadows S, Baker K, Butler J: The Incident Decision Tree: Guidelines for Action Following Patient Safety Incidents, vol. Advances in Patient Safety: From Research to Implementation (Volume 4: Programs, Tools, and Products). Rockville MD; 2005.

56. Miller R, Griffith S, Vogelsmeier A: A statewide approach to a just culture for patient safety: The Missouri story. Journal of Nursing Regulation 2010, 1(1):52-57

57. Marx DA: Patient safety and the" just culture": a primer for health care executives: Trustees of Columbia University; 2001.

58. Doran GT: There’sa SMART way to write management’s goals and objectives. Management review 1981, 70(11):35-36.

59. ECRI: Burns and Fires from Electrosurgical Active Electrodes. Health Devices 1993, 22(8-9):2.

60. ECRI: ESU Burns from Poor Return Electrode Site Preparation. Health Devices 1987, 16(1):2.

61. Donato M: Family Still Coming To Grips With Electrocution Of Baby. In: Chicago Tribune. 1993.

62. Newborn Is Electrocuted. In: New York Times. 1993.

63. Campbell EM, Sittig DF, Ash JS, Guappone KP, Dykstra RH: Types of unintended consequences related to computerized provider order entry. J Am Med Inform Assoc 2006, 13(5):547-556.

64. Saathoff A: Human factors considerations relevant to CPOE implementations. J Healthc Inf Manag 2005, 19(3):71-78.

65. Connolly C: Cedars-Sinai Doctors Cling to Pen and Paper. In: The Washington Post. 2005.

66. FDA: Preventing Tubing and Luer Misconnections > Examples of Tubing and Luer Misconnections. In. Edited by Health C-CfDaR. Rockville; 2015.

256

67. FDA: Guidance for Industry and Food and Drug Administration Staff – Total Product Life Cycle: Infusion Pump - Premarket Notification [510(k)] Submissions - Draft Guidance. In. Edited by Health C-CfDaR. Rockville; 2010.

68. Johnson TR, Zhang J, Patel VL, Keselman A, Tang X, Brixey JJ, Paige D, Turley JP: The role of patient safety in the device purchasing process. In.: DTIC Document; 2005.

69. Cassano AL: Applying human factors to the procurement of electrosurgical medical devices: a case study. In: Proceedings of the Human Factors and Ergonomics Society Annual Meeting: 2003. SAGE Publications: 1815-1819.

70. Cassano-Piché A, Cafazzo JA, Chagpar A, Easty AC: Choosing Safer Medical Technologies: How Human Factors Methods Can Help in the Procurement Process. Biomedical Instrumentation & Technology 2010, 44(s1):49-56.

71. Ginsburg G: Human factors engineering: A tool for medical device evaluation in ospital procurement decision-making. Journal of Biomedical Informatics 2005, 38(3):213-219.

72. Namshirin P, Ibey A, Lamsdale A: Applying a multidisciplinary approach to the selection, evaluation, and acquisition of smart infusion pumps. Journal of Medical and Biological Engineering 2011, 31(2):93-98.

73. Instrumentation AftAoM: ANSI/AAMI HE75: 2009: Human factors engineering: Design of medical devices. AAMI, Arlington 2009.

74. Israelski E: Overview of International Medical Device Human Factors Standards. In: Symposium on Human Factors and Ergonomics in Health Care: Bridging the Gap: 12-17 March 2012 2012. 2015.

75. Holden RJ, Karsh B-T: The Technology Acceptance Model: Its past and its future in health care. Journal of Biomedical Informatics 2010, 43(1):159-172.

76. Lapointe L, Rivard S: A multilevel model of resistance to information technology implementation. Mis Quarterly 2005:461-491.

77. Markus ML: Power, politics, and MIS implementation. Communications of the ACM 1983, 26(6):430-444.

78. Zuboff S: In the age of the smart machine: the future of work and power: Heinemann Professional; 1988.

79. Lorenzi NM, Riley RT: Managing change: an overview. J Am Med Inform Assoc 2000, 7(2):116-124.

80. Smith MJ, Carayon P: New technology, automation, and work organization: Stress problems and improved technology implementation strategies. International Journal of Human Factors in Manufacturing 1995, 5(1):99-116.

81. Lærum H, Ellingsen G, Faxvaag A: Doctors' use of electronic medical records systems in hospitals: cross sectional survey. BMJ 2001, 323(7325):1344-1348.

257

82. Davis FD: Perceived usefulness, perceived ease of use, and user acceptance of information technology. Mis Quarterly 1989:319-340.

83. Davis FD, Bagozzi RP, Warshaw PR: User acceptance of computer technology: a comparison of two theoretical models. Management Science 1989, 35(8):982-1003.

84. 84. Vicente KJ, Kada-Bekhaled K, Hillel G, Cassano A, Orser BA: Programming errors contribute to death from patient-controlled analgesia: case report and estimate of probability. Canadian Journal of Anesthesia 2003, 50(4):328-332.

85. Weinger MB, Pantiskas C, Wiklund ME, Carstensen P: Incorporating human actors into the design of medical devices. Jama 1998, 280(17):1484.

86. Abbott PCA Plus II patient-controlled analgesic pumps prone to misprogramming resulting in narcotic overinfusions. Health Devices 1997, 26(9-10):389-391.

87. Evidence builds: lack of focus on human factors allows error-prone devices. In: ISMP Medication Safety Alert. vol. 2013. Horsham, PA: Institute for Safe Medication Practices; 1999.

88. Lin L, Isla R, Doniz K, Harkness H, Vicente K, Doyle DJ: Applying Human Factors to the Design of Medical Equipment: Patient-Controlled Analgesia. Journal of Clinical Monitoring and Computing 1998, 14(4):253-263.

89. Fairbanks Rollin J, Caplan S: Poor Interface Design and Lack of Usability Testing Facilitate Medical Error. Joint Commission Journal on Quality and Patient Safety 2004, 30(10):579-584.

90. Gagnon R, Laberge J, Lamsdale A, Histon J, Hudson C, Davies J, Caird J: A User Centered Evaluation of three Intravenous Infusion Pumps. Proceedings of the Human Factors and Ergonomics Society Annual Meeting 2004, 48(15):1773-1777.

91. Kaye R, Crowley J: Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management. 2000.

92. Elliott M, Liu Y: The nine rights of medication administration: an overview. British journal of nursing (Mark Allen Publishing) 2010, 19(5):300-305.

93. Ontario CoNo: Practice Standard: Medication. In.; 2015.

94. Fluorouracil Incident Root Cause Analysis Report. In., vol. 2014. Toronto: Institute for Safe Medication Practices Canada; 2007.

95. Furniss D, Randell R, O’Kane AA, Taneva S, Mentis H, Blandford A: Fieldwork for healthcare: guidance for investigating human factors in computing systems. Synthesis Lectures on Assistive, Rehabilitative, and Health-Preserving Technologies 2014, 3(2):1-146.

258

Apéndice A: Confidencialidad y anonimato La mayoría de los métodos de factores humanos presentados en este libro requieren

el tiempo y la participación de los usuarios finales de la tecnología. Es importante que la información recolectada utilizando estos métodos sea tratada como confidencial y anónima, para proteger la reputación y la credibilidad de los participantes, y los encuestados suelen ser más honestos en estas condiciones. Los responsables de llevar a cabo métodos de factores humanos deben obtener el acuerdo de los gerentes clínicos y de todos los miembros del equipo o comité involucrados en la revisión de los datos de factores humanos, que todos los datos recopilados se mantendrán confidenciales y no serán utilizados de ninguna manera para evaluar la competencia clínica o exponerlos a riesgos profesionales. Ninguna acción disciplinaria debería resultar de la participación en pruebas de factores humanos.

La mejor práctica es no recoger o registrar cualquier información innecesaria de los participantes que esté identificando (por ejemplo, nombres de los participantes). Los números de participantes se pueden asignar para fines de comparación y referencia. Además, para ayudar a comunicar su compromiso con la confidencialidad y / o el anonimato, es importante obtener el consentimiento informado. Este propósito del consentimiento informado es asegurar que los participantes entiendan [95]:

los objetivos y métodos del estudio / proyecto;

que su participación es voluntaria, y que pueden retirarse en cualquier momento sin

ninguna consecuencia (y cómo se manejarán sus datos);

los riesgos y beneficios de su participación;

que sus datos serán anónimos y mantenidos confidenciales;

cómo se utilizarán y compartirán los resultados del estudio / proyecto (por ejemplo,

para tomar una decisión de adquisición);

Al final de esta sección se proporciona un formulario de consentimiento de muestra para su uso como plantilla.

El proceso de obtener el consentimiento informado generalmente implica asegurar que el participante entienda los puntos antes mencionados leyendo un documento de consentimiento que explique cada uno de los puntos y permita al participante tanto tiempo como sea necesario revisar el documento y hacer preguntas antes de decidir si participar, o no. Si eligen participar, deben firmar el documento de consentimiento.

Si usted está llevando a cabo un proyecto interno que involucra a los participantes y no es parte de un estudio de investigación y no hay planes para difundir las conclusiones fuera de la organización, es probable que baste usar un formulario de consentimiento que cubre los puntos descritos anteriormente sin requerir aprobación ética de la investigación. Sin embargo, se recomienda investigar si la aprobación ética es necesaria para el trabajo que usted está llevando a cabo antes de recopilar cualquier dato para asegurar que los datos puedan ser utilizados para su propósito y sin restricciones, como resultado de no obtener la

259

aprobación ética de la investigación. En términos generales, la aprobación ética de la investigación es necesaria si:

los datos que se recopilan son parte de un estudio de investigación.

existe la posibilidad de que los datos se utilicen para la investigación en una fecha

posterior.

Sin embargo, incluso las iniciativas de mejora de la calidad pueden presentar riesgos y deberían ser gestionados por un proceso formal de ética de la investigación. Para ayudar a determinar si éste es realmente el caso, puede usar la Herramienta de Evaluación de Ética de ARECCI en línea que se encuentra en http://www.aihealthsolutions.ca/arecci/screening/30863/6d62b234cf1570caeb290708caf72dd3, o pregunte directamente al comité de ética de la investigación de su organización.

Una discusión detallada del proceso de aprobación de la ética de la investigación en la asistencia sanitaria, en lo que se refiere específicamente a la realización de estudios de factores humanos se describe en el libro Trabajo de Campo para la Salud: Guías para la investigación de factores humanos en sistemas informáticos (95). Un capítulo gratuito del libro, que contiene las secciones relacionadas con la aprobación ética de la investigación y el consentimiento informado está disponible en:

http://www.morganclaypool.com/doi/suppl/10.2200/S00606ED1V02Y201410ARH007/s uppl_file / Furniss_Ch1.pdf.

260

Ejemplo de formulario de consentimiento

CONSENTIMIENTO PARA PARTICIPAR EN UN ESTUDIO DE USABILIDAD

Introducción

Se le pide que participe en un estudio de usabilidad. Lea esta explicación sobre el estudio y sus riesgos y beneficios antes de decidir si desea participar. Usted debe tomar tanto tiempo como sea necesario para tomar su decisión. Debe pedirle al personal del estudio que explique cualquier cosa que no entienda y asegúrese de que todas sus preguntas hayan sido contestadas antes de firmar este formulario de consentimiento. Antes de tomar su decisión, siéntase libre de hablar sobre este estudio con cualquiera que usted desee. la participación en este estudio es voluntario.

Propósito

El propósito de este proyecto es [insertar propósito aquí]. Su participación nos ayuda a determinar [insertar beneficio aquí como "identificar qué producto es el más seguro para su unidad"].

Procedimientos

Si acepta participar en el estudio, se recogerá su información demográfica (por ejemplo, edad, sexo, años de experiencia de enfermería) y se le pedirá que complete una serie de tareas clínicas en un entorno clínico simulado. En otras palabras, usted estará en una sala con equipo clínico y escenarios, pero no pacientes reales o atención al paciente. Se le enseñará cómo utilizar los dispositivos que no están en uso rutinario en su unidad antes de iniciar las simulaciones. Después del entrenamiento se orientará al entorno simulado y se le pedirá que realice varias tareas a un paciente simulado (maniquí y / o actor). Después de cada escenario, le pediremos sus comentarios basados en nuestras observaciones para comprender mejor los riesgos y beneficios de los dispositivos que se están probando. La sesión durará no más de 3 horas, y se grabará en video para su posterior análisis. Su desempeño / competencia NO se está evaluando de una manera que afectará su empleo, sino que los resultados de este estudio se utilizarán para entender mejor problemas relacionadas con los dispositivos que estamos evaluando.

Riesgos

No hay riesgos médicos previstos o conocidos asociados con este estudio. Usted puede experimentar incomodidad al compartir sus opiniones con los investigadores. Solo tienes que compartir tanto como quieras tus opiniones. Su participación NO tendrá ningún impacto en su empleo.

261

Beneficios

Usted puede o no recibir beneficios directos de participar en este estudio. La información de este estudio puede ayudar a aumentar su conocimiento sobre [inserte el tipo de dispositivo aquí].

Participación voluntaria

Tu participación en este estudio es voluntaria. Puede optar por no participar o puede retirarse en cualquier momento. Si usted elige participar o no, no tiene ningún impacto en su empleo. De ninguna manera con la firma de este formulario de consentimiento renuncia a sus derechos legales ni libera a los investigadores, patrocinadores o involucrados de sus responsabilidades legales y profesionales. Usted no renuncia a ninguno de sus derechos legales firmando este formulario de consentimiento.

Confidencialidad

Toda la información obtenida durante el estudio se mantendrá en estricta confidencialidad. Sólo se identificará con un número de sujeto únicamente. No se utilizarán nombres ni información de identificación en los informes, publicaciones o presentaciones que puedan venir de este estudio. Ninguna información que lo identifique será transferida fuera de los investigadores de este estudio. Si los videos de la investigación se muestran fuera del equipo de investigación, su rostro será borroso y toda la información de identificación se hará anónimo. Sin embargo, a pesar de los mejores esfuerzos, hay una posibilidad muy pequeña de que todavía puede ser identificado. Los datos del estudio (por ejemplo, cintas de video, registros en papel) se mantendrán durante un mínimo de dos años y un máximo de siete años, una vez finalizado el estudio. Cualquier información personal identificable será almacenada y protegida en servidores seguros o guardada en un archivador cerrado y luego destruida por trituración de papel o borrado de información digital.

Reembolso

Usted no recibirá ningún reembolso financiero por su participación.

Preguntas

Si tiene alguna pregunta, preocupación o quiere hablar con el equipo del estudio por cualquier razón, por favor comuníquese con [insértese el nombre del contacto y la información de la persona responsable del estudio).

262

Consentimiento

Este estudio se me ha explicado y todas las preguntas que he tenido han sido contestadas. Sé que puedo dejar el estudio en cualquier momento. Acepto participar en este estudio.

_______________________________________________________________________________

Nombre del participante del estudio (por favor escriba en letra de imprenta)

_______________________________________________________________________________

Firma del participante

Fecha:

(Se le dará una copia firmada de este formulario de consentimiento)

Mi firma significa que he explicado el estudio al participante nombrado arriba. He contestado todas las preguntas.

________________________________________________________________________

Nombre de la persona que obtiene el consentimiento

__________________________________________________________________________

Firma

Fecha:

263

Sobre los autores

Andrea Cassano-Piché, MASc, PEng

Andrea es un ingeniero de factores humanos. Se graduó en Ingeniería Industrial en la Universidad de Toronto. Desde 2002, ha estado aplicando métodos de factores humanos al diseño y evaluación de tecnologías de salud y conduciendo investigaciones proactivas y retrospectivas de temas de seguridad del paciente. Los intereses de investigación de Andrea incluyen el manejo proactivo de riesgos de sistemas de salud complejos y la creación de capacidad de factores humanos dentro de la salud como un medio para transformar la cultura de la seguridad de la salud.

cassanopiche@gmail.com

https://ca.linkedin.com/in/cassanopiche

Patricia Trbovich, PhD

Patricia es la Jefe de Investigación del Equipo HumanEra de la University Health Network. Es Profesora Asistente del Instituto de Biomateriales e Ingeniería Biomédica y de Informática de Salud del Departamento de Salud, Políticas, Gestión y Evaluación de la Facultad de Medicina de la Universidad de Toronto. Sus áreas de especialización incluyen la ingeniería de factores humanos y la seguridad del paciente

patricia.trbovich@uhn.ca

https://ca.linkedin.com/in/patriciatrbovich

Melissa Griffin, MHSc, PEng

Melissa es ingeniera clínica y especialista en factores humanos. Recibió su Maestría en Ciencias de la Salud en Ingeniería Clínica de la Universidad de Toronto. Su trabajo se ha centrado en la aplicación de métodos de factores humanos a una amplia gama de entornos de salud, incluyendo el cuidado del hogar y la oncología. Ella es apasionada por mejorar la seguridad de los pacientes a través de nuestro sistema de salud y enseñar a otros a aplicar esta forma de pensar en su trabajo diario.

melissa.griffin@uhn.ca

https://ca.linkedin.com/in/melissagriffin4

264

Ying Ling Yin, MEng, candidato de doctorado.

Ying Ling recibió su licenciatura y maestría en ingeniería de la Universidad McGill. Continúa sus estudios de postgrado en la Universidad de Toronto, donde investiga factores humanos en ambientes médicos complejos y de alta tecnología. Sus intereses incluyen la seguridad del paciente en escenarios con recursos limitados y métodos de factores humanos como un medio para diseñar sistemas de salud más seguros y apropiados.

ylin@metalin.ca

https://ca.linkedin.com/in/yinglinglin

Anthony (Tony) Easty, Ph D, PEng, CCE

Tony es Científico Senior y Titular Inaugural de la Cátedra Baxter en Tecnología de la Salud en la University Health Network / Universidad de Toronto. También es profesor asociado en el Instituto de Biomateriales e Ingeniería Biomédica de la universidad. El enfoque de la investigación del Dr. Easty se centra en la usabilidad y la seguridad de las tecnologías médicas en todo el sistema de atención de la salud, con especial énfasis en la seguridad y seguridad de los medicamentos en el cuidado del hogar. Ha establecido el Equipo HumanEra, formado en los niveles de doctorado y maestría en ingeniería de factores humanos, psicología cognitiva e ingeniería biomédica.

tony.easty@utoronto.ca

https://ca.linkedin.com/in/tonyeasty