3. GESTIÓN REACTIVA DE RIESGOS SANITARIOS
Este tipo de gestión de riesgos es la que se realiza tras la ocurrencia de los incidentes, lo que se suele denominar “a toro pasado”. Han fallado las barreras de seguridad de la organización y, los errores, han tenido (o no) un efecto en el estado de salud del paciente.
Para saber cuáles han sido los riesgos ya sucedidos en las diferentes áreas de la organización, es decir, para la Identificación Reactiva de riesgos, hay que tener en cuenta qué Fuentes de Información existen, ya que serán las que nos van a aportar estos datos.
En el caso de una organización asistencial, las fuentes de información son varias:
- Sistemas de registro de información:
- CMBD´s: registran información de los diagnósticos y tratamientos, comorbilidades.
- Estudios de Prevalencia e Incidencia: EPINE, ENVIN-HELICS.
- Registro de úlceras y registro de caídas.
- Planes de vigilancia de infecciones.
- Reacciones adversas (a medicamentos, a productos sanitarios, a transfusión, etc.)
- Sistemas de notificación de incidentes:
- Notificación de incidentes de seguridad (tipo SINASP, SENSAR).
- Servicio de Atención al Paciente (SAPU).
- ISMP: incidentes de medicación.
- EDO: enfermedades de notificación obligatoria (Gripe, diferentes virus como ébola, enfermedades infecciosas en general).
- Estudio de Eventos Centinela que son: aquellos incidentes o sucesos inexplicados que producen la muerte o secuelas físicas y/psicológicas importantes, o bien el riesgo de éstas a un paciente.
- Informes de satisfacción del paciente (encuestas, grupos focales/nominales).
- Reportes diarios en los servicios/unidades.
- Revisión de historia clínica.
- Demandas judiciales anteriores
Es necesario conocer tanto la Frecuencia de aparición del riesgo como la Gravedad e impacto que ha supuesto para el estado del paciente, es decir, realizar el Análisis Reactivo de los riesgos identificados. Esta información será también fuente de fiabilidad de los datos para la gestión proactiva de los riesgos, ya que determinará la definición cuantitativa de cada factor de análisis de los riesgos basándose en hechos reales de la organización. Tras el análisis y, en base a una matriz de priorización conforme los factores de frecuencia y gravedad, se evalúa cada riesgo para conocer el nivel de criticidad, ya que, aquellos riesgos ocurridos con un impacto importante en el paciente, deberán ser abordados por la organización.
Tras la ocurrencia de un riesgo que no ha podido detectarse, urge la necesidad de ser abordado de cara a conocer dónde han fallado las defensas del sistema y contribuir a su fortalecimiento o a establecer nuevas medidas de seguridad, sobre todo en los casos en los cuales el impacto del incidente ha sido crítico.
Existen diferentes herramientas facilitadoras de este proceso de abordaje de los riesgos tras su ocurrencia.
Las herramientas más habituales son el Análisis Causa-Raíz (ACR), el London Protocol (análisis sistémico de incidentes clínicos) y el SEA (análisis de eventos significativos). Existen otras herramientas de apoyo al análisis reactivo de incidentes que pueden ayudar a la identificación de causas: flujograma, árbol de decisión, tabla de cronología, lluvia de ideas o brainstorming, grupo nominal, diagrama causa-efecto, los 5 por qués.
SEA
Se usa para analizar incidentes sin daño o leves. Se delibera sobre cuáles son las causas subyacentes y se valora si se han llevado a cabo las recomendaciones dadas en eventos anteriores, para finalizar dando una serie de recomendaciones, pero de carácter general.
London Protocol
Se basa en el modelo del error de Reason. Se usa para cualquier tipo de incidente,descubre una serie de eventos concatenados que condujeron al resultado adverso, identificando aquellas desviaciones con respecto a una buena práctica, así como acciones inseguras que se han llevado a cabo. Sus fases son siete:
- Identificación y decisión de investigar: es interesante investigar los incidentes que, aunque no llegan a producir daño gracias a las medidas de seguridad establecidas o a la actuación de los profesionales, son de suficiente relevancia por estar provocados por los mismos factores que los eventos adversos, con base en la Teoría de Bird o Pirámide de Heinrich (Anexo 4).
- Selección del equipo de investigación, recomendándose el carácter multidisciplinar.
- Organización y recogida de datos: en base a diferentes fuentes de información como historia clínica, protocolos, visita al lugar del incidente, etc. y se debe responder a cómo debería haberse realizado la actividad/proceso tal como está diseñado y qué ocurrió realmente.
- Cronología del incidente: se debe trazar lo ocurrido de manera precisa.
- Identificación de problemas: identificar desviaciones entre lo correcto y lo que ocurrió realmente.
- Identificar factores contribuyentes: para cada una de las desviaciones identificadas.
- Medidas correctoras para cada uno de los factores contribuyentes.
Análisis Causa Raíz (ACR)
Es la herramienta más utilizada para el análisis reactivo de riesgos de impacto crítico y/o eventos centinela. Se usa para conocer las causas raíces teniendo en cuenta los factores que han propiciado el error en el profesional que se vio implicado, así como los factores predisponientes en el entorno, en los equipos, en el paciente, en la tarea y en la institución. Sus fases son las siguientes:
- Identificar eventos a investigar: lo interesante es investigar aquellos que tengan relevancia, en función del impacto en el paciente. Como ya hemos dicho, los eventos centinela serán el objeto de estudio mediante esta herramienta.
- Creación del equipo de trabajo, de carácter multidisciplinar, en el que participen personas involucradas en el incidente.
- Recabar información: en base a diferentes fuentes de información como historia clínica, protocolos, visita al lugar del incidente, notificación de incidentes, entrevistas, examen de las instalaciones, revisión del estado de los equipos y dispositivos médico-quirúrgicos.
- Elaboración del mapa de los hechos: realización de un flujograma en el que se reconstruyen los hechos paso a paso tal como condujeron al incidente.
- Análisis de la información: identificación de las causas subyacentes que han podido ocasionar el incidente. Para este análisis la herramienta que más se utiliza es el Diagrama de Ishikawa o Espina de Pescado (Anexo 5), la cual permite conocer los factores desencadenantes, a nivel macro (causas primeras) y, en cada uno de ellos, las posibles causas secundarias subyacentes.
- Análisis de barreras y plan de control: cuáles son las medidas seguras que han fallado, cuáles no existían y deberían existir, por qué han fallado. Así mismo, definidas las actividades a realizar, el cronograma de las mismas, los recursos necesarios, los indicadores de control y evaluación y los responsables y profesionales involucrados en su desarrollo.
- Desarrollo de soluciones y plan de implementación: trasladar los cambios propuestos a las área y procesos de la organización, de forma gradual para evitar riesgos secundarios.
- Elaboración de informe final: que incluirá las recomendaciones y soluciones identificadas. Importante es su difusión a toda la organización para su conocimiento y aprendizaje de lo analizado.
4. SISTEMAS DE NOTIFICACIÓN DE INCIDENTES DE SEGURIDAD
Uno de los pilares básicos de una cultura de seguridad clínica es disponer de sistemas de información que nos permitan conocer cómo y por qué se están produciendo incidentes, y que permitan trabajar en el análisis de sus causas. Estos sistemas forman parte del enfoque reactivo de la gestión de riesgos asistenciales, permiten identificar fallos en los sistemas de defensa para adoptar medidas que fortalezcan dichas barreras o instaurar otras más eficaces.
4.1. DEFINICIÓN DE SISTEMA DE INFORMACIÓN. TIPOLOGÍAS
Conjunto de datos enlazados entre sí racionalmente sobre una materia determinada, para la comunicación o adquisición de conocimientos que permiten ampliar o precisar los que se poseen sobre dicha materia.
En el apartado anterior ya señalamos los diferentes sistemas de información existentes en el ámbito asistencial: sistemas de registro y sistemas de notificación. Ahora vamos a conocerlos en profundidad.
Sistemas de Registro: CMBD´s, EPINE, ENVIN...
Conjunto de datos relacionados entre sí por una o más características, que constituyen una unidad de información en una base de datos y que, de su análisis agregado, pueden monitorizarse uno o más eventos relacionados con la seguridad. Por lo que la función de estos sistemas es la Monitorización (conocer cuánto).
Permiten estimar la frecuencia de los eventos registrados, ya que se cuenta con información de suceso (numerador) y de los pacientes que han estados expuestos a un riesgo determinado (denominador).
Es un sistema costoso de mantener porque consume mucho tiempo, mucho recurso humano, hay que recoger diferentes variables, se maneja un importante volumen de datos y el análisis cuantitativo puede ser bastante complejo.
Sistemas de Notificación: SINASP, SNASP, AVIZOR...
Conjunto de datos obtenidos de la comunicación voluntaria u obligatoria, de uno o más tipos de sucesos relacionados con la seguridad asistencial. Por lo que la función de estos sistemas es el Aprendizaje de cada caso. Es a través de este tipo de sistemas mediante los cuales los profesionales realizan notificaciones acerca de las circunstancias en las que se producen los incidentes de seguridad con el objetivo de poder aprender de cada caso.
Estos sistemas están sujetos a legislación estatal y/o autonómica, entre otras:
- Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal.
- Ley 41/2002 de 14 de noviembre básica reguladora de la Autonomía del paciente y de derechos y obligaciones en materia de información y documentación clínica.
- Decreto 78/2016 de 17 de mayo sobre medidas de seguridad de pacientes que reciban asistencia sanitaria en los centros y servicios sanitarios ubicados en Euskadi.
Se trata de un sistema menos costoso que el anterior puesto que recoge pocas variables y prevalece la libre descripción del suceso, el volumen de datos está supeditado a la sensibilización del declarante y el análisis suele ser cualitativo.
4.2 CARACTERÍSTICAS DE LOS SISTEMAS DE NOTIFICACIÓN
Los sistemas para notificar incidentes pueden tener formato papel, puede ser un software informatizado o incluso una app para móviles. Se caracterizan por:
- Voluntariedad: lo recomendable es que sean voluntarios, puesto que deben formar parte de la sistemática de gestión de la seguridad del paciente. Los sistemas que se enfocan hacia la mejora de la seguridad son los sistemas de carácter voluntario. Normalmente se centran en los incidentes sin daño o en errores que han producido daño mínimo. Su objetivo es identificar áreas o elementos vulnerables del sistema, formar a los profesionales sobre lo aprendido con el análisis de múltiples casos, a objeto de evitar que se repitan los daños en los pacientes. No obstante, podrían ser obligatorios por ley o por adecuación de la organización sobre todo en el caso de recoger información sobre eventos que puedan tener impacto en la comunidad (Ej. Sistema de Notificación de Reacciones Adversas a medicación).
- Anonimato: indica el conocimiento o no de los sujetos declarantes e intervinientes en el incidente. Lo recomendable es que sean anónimos.
- Especificidad: son específicos si recogen información sobre un tipo concreto de evento o casos relacionados por un factor comunitario. Son genéricos cuando los eventos no tienen que estar relacionados entre sí (aunque puede darse la posibilidad de vinculación de incidentes dentro del programa)
- No Punitivos: es importante que el objetivo de la notificación no sea conocer quién se ha visto involucrado en el incidente para imponerle una sanción puesto que esto queda fuera de una organización enfocada a la cultura de seguridad clínica.
- Localización:
- De gestión local: son menos confidenciales, de aprendizaje cerrado, el análisis es más preciso y rápido, las medidas se ajustan más a las peculiaridades del entorno (quienes proponen las medidas correctoras son los propios profesionales que conocen las limitaciones del área de trabajo).
- De gestión centralizada: son más confidenciales, el aprendizaje es más abierto, los análisis menos precisos y lentos, las medidas son generales.
Notificación de Eventos adversos y Eventos Centinela
Para la notificación de este tipo de incidentes, las organizaciones desarrollan sistemas obligatorioslos cuales ponen el acento en proporcionar al público unos mínimos de protección, en ser un incentivo para que las instituciones eviten problemas de seguridad que les podrían conducir a sanciones y, en último lugar, en exigir a las organizaciones inversiones en recursos para la seguridad del paciente.
Una buena práctica en relación a notificar estos incidentes, es el desarrollo de un procedimiento específico que sirva de guía a los profesionales y facilite el conocimiento del circuito y la sistemática para esta notificación. Estos incidentes son de impacto crítico en los pacientes y la organización, con lo que es necesario determinar pautas de actuación para todas las víctimas (primeras, segundas y terceras).
La NPSA británica ha desarrollado un listado denominado “Never Events” sonde se señalan los incidentes considerados centinela y de obligatoria notificación para la mejora de la seguridad de los pacientes en las organizaciones sanitarias (Anexo 6).
4.3. INFORMACIÓN QUE DEBEN RECOGER LOS SISTEMAS DE NOTIFICACIÓN (SEGÚN JCAHO)
- Descripción de lo ocurrido:
- Ámbito (Dónde, cuándo).
- Impacto (Afectó al paciente, produjo daño, gravedad).
- Con qué tiene relación (Medicación, procedimientos, pruebas, equipos...).
- Relato del acontecimiento (Texto libre)
- Causas latentes del sistema.
- Barreras / defensas (qué evitó que el incidente llegara a afectar al paciente o que el daño fueras de mayor gravedad).
4.4. BARRERAS PARA LA NOTIFICACIÓN
Uno de los principales problemas de la notificación de incidentes es la reticencia que existe precisamente para declarar incidentes por:
- Falta de liderazgo para la gestión de incidentes (la alta dirección no considera este ámbito como parte de la estrategia).
- Miedo a represalias.
- Falta de conciencia de la ocurrencia de un incidente.
- Falta de conocimiento de lo que se debe declarar.
- Desconocimiento de la existencia y/o funcionamiento de los sistemas de notificación.
- Una vez que se notifica, existe poco feedback en relación al análisis y tratamiento del incidente notificado.
- Considerar que requiere inversión de tiempo