Morbimortalidad quirúrgica: preparar la reunión con datos, no con memoria

Morbimortalidad quirúrgica: preparar la reunión con datos, no con memoria

Una reunión de morbimortalidad quirúrgica se vuelve lenta cuando el equipo dedica la primera mitad a decidir qué casos revisar, reconstruir fechas y discutir cuál es la versión correcta de un dato. La solución no es preparar presentaciones más largas. Es llegar con los episodios seleccionados, el evento postoperatorio estructurado, las decisiones registradas y los pendientes visibles.

La reunión debe servir para entender qué ocurrió y qué puede cambiarse. Para conseguirlo, el servicio necesita un circuito sencillo: registrar el evento cerca del momento en que se detecta, relacionarlo con el episodio quirúrgico, completar su evolución, marcarlo para revisión y generar la agenda desde el propio registro. Así la sesión clínica revisa hechos y decisiones, no recuerdos dispersos.

La respuesta práctica: una ficha común y una agenda que se genere sola

Antes de convocar una sesión, cada caso debería responder a las mismas preguntas:

• ¿Qué episodio quirúrgico se está revisando?
• ¿Qué ocurrió y cuándo se detectó?
• ¿Qué gravedad y consecuencias tuvo?
• ¿Qué actuaciones se realizaron?
• ¿Cómo evolucionó el paciente?
• ¿Qué datos faltan por confirmar?
• ¿Por qué se incluye en la reunión?
• ¿Qué decisión o acción queda después de revisarlo?

No hace falta convertir la sesión en un formulario interminable. Hace falta que los campos importantes tengan una definición estable y que el equipo pueda distinguir un evento abierto de uno revisado, una complicación en seguimiento de una ya cerrada y un caso pendiente de comité de uno que solo está registrado para continuidad asistencial.

Por qué la memoria no basta

La memoria clínica es imprescindible para interpretar un caso, pero no es una base de datos. Bajo presión, las personas recuerdan antes el desenlace que la secuencia completa. Una reintervención puede ser muy visible y hacer que se olviden una demora previa, un cambio de prioridad o una señal que ya estaba registrada. Otro caso puede quedar fuera porque la complicación se comunicó en una llamada y nunca se añadió a la lista de revisión.

La solución es separar dos trabajos. El registro recoge los hechos y mantiene su evolución. El comité interpreta esos hechos, contrasta decisiones y define mejoras. Cuando ambos trabajos se mezclan en una presentación manual, el equipo discute primero los datos y después, si queda tiempo, la calidad.

Definir qué casos entran en la sesión

Un comité necesita un criterio de inclusión que se pueda aplicar de forma consistente. Puede combinar gravedad, resultado, reintervención, reingreso, estancia prolongada, fallecimiento, evento inesperado o una decisión del responsable del módulo. El criterio exacto corresponde al servicio, pero no debería depender de quién recuerda un caso esa semana.

El registro debe permitir marcar un episodio para morbimortalidad y conservar el motivo. También conviene distinguir entre “candidato a revisión”, “incluido en agenda”, “revisado” y “con acciones pendientes”. Son estados de trabajo, no etiquetas decorativas. Permiten que el coordinador sepa qué debe preparar y que el equipo pueda comprobar si una sesión cerró realmente sus compromisos.

La ventana temporal también debe estar clara: complicaciones detectadas, casos operados o eventos aún abiertos. Mezclar periodos sin indicarlo dificulta interpretar listas y resultados. Un dashboard puede filtrar por fecha, módulo, procedimiento, gravedad o estado si esas variables se registran con el mismo significado.

Registrar el evento cerca de cuando ocurre

El mejor momento para registrar una complicación es cuando el equipo la detecta y puede describirla con precisión suficiente para iniciar el seguimiento. No hace falta cerrar toda la historia en una sola entrada. El evento puede comenzar con un estado abierto y completarse conforme se confirma la gravedad, el tratamiento y la evolución.

Una ficha operativa debería separar al menos cinco bloques:

1. Contexto del episodio. Procedimiento, módulo quirúrgico, fecha relevante y responsables del caso.
2. Descripción del evento. Tipo de complicación, momento de detección y relación con la intervención.
3. Respuesta clínica. Actuaciones realizadas, cambios de plan, reintervenciones, reingresos u otras consecuencias que el servicio haya decidido registrar.
4. Evolución. Estado actual, fecha de revisión y si el seguimiento continúa.
5. Revisión de calidad. Motivo de inclusión, preguntas para la sesión, decisiones y acciones posteriores.

Los campos estructurados permiten agrupar eventos y encontrar pendientes; las notas aportan contexto, pero no deberían ser la única forma de saber si un caso necesita revisión. Si el servicio utiliza una clasificación de gravedad, debe acordar cuándo se asigna y qué ocurre si cambia durante la evolución. La plataforma puede conservar el cambio y su fecha para que la reunión entienda la secuencia sin reconstruirla desde mensajes.

Preparar la agenda sin hacer otra hoja

La agenda de la reunión debería salir del registro con filtros explícitos. Por ejemplo, se pueden seleccionar los casos marcados para revisión, limitar por periodo y ordenar por módulo o tipo de evento. El responsable debe ver qué información está completa y qué campos siguen pendientes antes de cerrar la convocatoria.

Una preparación útil incluye, como mínimo:

• Lista de casos incluidos y motivo de inclusión.
• Estado de cada evento: abierto, en seguimiento, revisado o cerrado.
• Datos pendientes de confirmar.
• Responsable que presenta o prepara el caso.
• Pregunta concreta que la sesión debe responder.
• Acciones abiertas de reuniones anteriores.

Así la reunión no se convierte en una sucesión de relatos. Cada caso llega con un objetivo. Puede ser aclarar una decisión, revisar una demora, comprobar una transición asistencial o decidir una modificación del circuito. El sistema no reemplaza la conversación clínica; evita gastar esa conversación en localizar información básica.

Las notificaciones pueden avisar al responsable cuando un evento se marca para revisión, falta cerrar un dato o se acerca una acción. Un aviso solo sirve si lleva a una tarea identificable.

Un dashboard que ayude a preguntar mejor

El dashboard de morbimortalidad no debe limitarse a mostrar un número grande de complicaciones. Ese número, aislado, no explica si el registro está completo, si los eventos siguen abiertos o si ha cambiado el volumen de actividad.

Algunas vistas de trabajo pueden ser más útiles:

• Eventos por módulo, procedimiento y periodo.
• Casos abiertos o pendientes de validar.
• Distribución por gravedad acordada por el servicio.
• Reintervenciones y reingresos relacionados con el episodio.
• Tiempo desde la detección hasta la revisión.
• Casos marcados para la próxima sesión.
• Acciones de reuniones anteriores que siguen abiertas.

Cada indicador necesita una definición. “Complicación” no puede significar una cosa en un módulo y otra en otro sin que el dashboard lo advierta. Tampoco conviene comparar periodos si ha cambiado el criterio de registro. El dashboard organiza la pregunta; no la responde por sí solo.

Roles distintos para registrar, revisar y administrar

La trazabilidad no exige que una sola persona controle todo. Al contrario: la revisión mejora cuando cada perfil tiene una responsabilidad clara. Un profesional puede registrar el evento inicial. El responsable del módulo puede confirmar datos clínicos o gravedad. La coordinación puede preparar la agenda y seguir acciones. La administración puede gestionar usuarios, módulos y permisos sin necesidad de editar el contenido clínico.

Los roles deben reflejar el trabajo real. No todo usuario necesita editar eventos cerrados, exportar el registro completo o cambiar la configuración del módulo. Limitar esas acciones reduce cambios accidentales y hace más fácil interpretar el historial.

La auditoría de cambios debe responder a tres preguntas sencillas: quién modificó el dato, qué cambió y cuándo ocurrió. Si se corrige la gravedad, se añade una reintervención o se retira un caso de la agenda, el registro debe conservar esa huella. No se trata de convertir cada edición en una investigación. Se trata de que el equipo pueda distinguir una corrección documentada de una versión contradictoria.

La cultura de revisión importa tanto como el formulario

Un sistema puede tener buenos campos y una sesión puede seguir siendo punitiva. La morbimortalidad debe revisar hechos, decisiones, contexto y oportunidades de mejora. Registrar un evento no debería interpretarse como admitir un fracaso personal. Si el equipo teme que el dato se use fuera de su propósito, registrará tarde o dejará la información incompleta.

Un circuito de cuatro momentos

Para hacer sostenible la reunión, conviene repartir el trabajo:

1. Durante la asistencia: registrar el evento, asociarlo al episodio y dejarlo abierto si la evolución continúa.
2. Antes de la sesión: filtrar candidatos, comprobar datos pendientes, asignar presentadores y recuperar acciones anteriores.
3. Durante la revisión: discutir hechos, decisiones, factores contribuyentes y cambios concretos; no rehacer la cronología desde cero.
4. Después de la sesión: registrar decisiones, responsables y fechas, y hacer visibles las acciones hasta su cierre.

Una decisión sin responsable ni fecha es una recomendación, no una acción. Las notificaciones y los estados ayudan a que las tareas no desaparezcan después de la reunión.

Cómo empezar sin rediseñar todo el hospital

Un piloto pequeño suele ser más útil que un despliegue general. Durante cuatro semanas, un módulo puede seleccionar un conjunto controlado de episodios, definir los campos mínimos y seguirlos desde la detección del evento hasta el cierre de las acciones.

• Semana 1: acordar criterios de inclusión, estados, campos obligatorios y responsables.
• Semana 2: configurar el registro, los roles y la vista de agenda; probar con casos simulados o anonimizados.
• Semana 3: preparar una sesión con el circuito completo y medir qué datos faltan, qué avisos sobran y cuánto trabajo manual queda.
• Semana 4: revisar las decisiones de la sesión, comprobar el seguimiento y decidir qué ampliar o simplificar.

La prueba debe incluir casos incómodos: un evento cuya gravedad cambia, una reintervención que se registra después y una acción que queda pendiente. Si el sistema solo funciona con el caso perfecto, no está listo para la reunión real.

Cómo encaja Chronosurg

Chronosurg conecta registro de pacientes, módulos por especialidad, programación quirúrgica, seguimiento, dashboards, notificaciones, roles, administración, tenants y auditoría de cambios. En un circuito de morbimortalidad, esa conexión permite asociar el evento al episodio, mantener su evolución, filtrar los casos de revisión y seguir las acciones posteriores sin crear una hoja paralela como fuente principal.

La plataforma no interpreta el caso ni decide qué debe aprender el servicio. El equipo clínico conserva esa responsabilidad. Chronosurg aporta una estructura común para que la sesión llegue con datos localizables, estados comprensibles y cambios trazables. El resultado buscado no es una reunión más tecnológica. Es una reunión que dedica más tiempo a entender y menos a reconstruir.

Una sesión de morbimortalidad preparada con datos no elimina la incertidumbre clínica. Elimina una incertidumbre más básica y evitable: no saber qué ocurrió, qué falta por confirmar o qué se acordó la última vez. Ese es el primer paso para convertir la revisión en mejora real.