Una funeraria grande de Latinoamérica sabe, con exactitud de dos decimales, cuántas sillas salieron a un servicio y cuántas volvieron. Sabe cuáles volvieron rotas y por lo tanto no reingresan al inventario. Y si falta una, el sistema no deja cerrar la orden: dice exactamente qué falta y se niega. Esa disciplina no es una aspiración de un manual de calidad: está escrita en el código, en un puñado de funciones que ni siquiera tocan la base de datos, y se comprueba con una suite de pruebas dedicada.
La misma empresa, esa misma noche, no puede responder con la misma certeza dónde está cada cuerpo que recibió hoy ni qué traspasos quedaron abiertos. No porque le falte un modelo de inteligencia artificial: porque la ecuación que existe para las sillas no está escrita para el cuerpo.
Este artículo es el caso de uso completo de un agente de IA que trabaja sobre esa asimetría: cada noche, en solo lectura, recorre los traspasos del día, encuentra los que quedaron sin cerrar y deja una lista corta priorizada al coordinador de sede. No cierra nada. No firma nada. No avisa a la familia. Y su valor no está en el modelo, sino en las cuatro preguntas que sabe hacerle a datos que ya existen. Si buscas el marco de proceso —qué traspasos hay, qué debe registrar cada uno y quién responde—, está en la guía de cadena de custodia del cuerpo en grupos funerarios; aquí vamos al caso operativo.
El problema: el traspaso que nadie cerró
La cadena de custodia no se rompe de forma dramática. Se rompe en el hueco administrativo entre dos personas que hicieron bien su trabajo. El conductor entregó el cuerpo en la sala de tanatopraxia a las 2:40 de la madrugada; el tanatopractor lo recibió; nadie volvió al sistema a cerrar el traslado. A las nueve de la mañana el registro dice, textualmente, que ese traslado sigue “En proceso”. A las nueve del día siguiente sigue diciendo lo mismo. Nadie está mintiendo y nadie está en falta: el sistema simplemente no tenía por qué enterarse.
Para la dirección, el costo de ese hueco aparece siempre tarde y siempre por una vía cara. Una reclamación de la familia que no se puede contestar porque el expediente no demuestra la secuencia. Una inspección sanitaria que pregunta por trazabilidad y recibe una carpeta reconstruida a mano. Una auditoría interna que descubre que dos expedientes con el mismo apellido y un dígito de diferencia en la cédula son la misma persona. Un servicio subcontratado que se facturó dos veces porque nadie sabe si el traslado se ejecutó. Ninguno de esos casos se previene con más gente revisando pantallas: se previenen preguntando, todas las noches, lo mismo.
Qué tan grande es el problema (y por qué escanear no lo resuelve)
No existe ninguna cifra publicada de tasa de error de identificación en funerarias comerciales de Latinoamérica, y conviene decirlo antes que nada: quien te ofrezca una, se la inventó. Lo que sí existe es evidencia del sector mortuorio público bajo regulador, y de dos industrias que llevan décadas midiendo exactamente este modo de falla.
El análisis de contenido de los incidentes graves reportados a la base de datos nacional del sistema de salud inglés encontró 132 incidentes ocurridos después del fallecimiento; 31 de ellos fueron de disposición del cuerpo, e incluyeron 25 cuerpos entregados por error a la funeraria, de los cuales 9 terminaron enterrados o cremados por la familia equivocada. La causa de fondo que identifican los autores no es tecnológica: es debilidad o incumplimiento del protocolo. En la misma línea, el regulador británico de tejidos humanos registró 50 incidentes de entrega del cuerpo equivocado entre 2021 y 2024, y nombra dos causas raíz concretas: liberar el cuerpo verificando solo uno o dos identificadores cuando el estándar exige tres, y no comprobar los tres puntos de identificación en el momento de la entrega.
Lo interesante es la mitigación que recomienda el propio regulador: auditorías de proceso periódicas, incluidas no anunciadas, y auditorías de ubicación e identificación que corrijan inconsistencias. Es decir, la norma ya pide el trabajo que describe este artículo. Hoy se hace a mano y por muestreo. El agente no inventa una práctica nueva: automatiza la parte de una práctica exigida que ninguna organización alcanza a cubrir al 100 % con personas.
La tentación de resolverlo con un lector de códigos
La respuesta intuitiva a un problema de identificación es poner un brazalete con código y un lector en cada puerta. Es una buena idea y es insuficiente, y hay evidencia directa de ambas cosas.
- Funciona: comparando más de 1,6 millones de muestras con identificación manual contra más de 0,5 millones con identificación electrónica, la tasa de “sangre equivocada en el tubo” pasó de 1 en 3.046 a 1 en 14.606. Cinco veces menos error.
- No lo elimina: ese mismo estudio no llega a cero. Y en un análisis posterior de 331 errores en 36 centros de 11 países, en 43 casos la identificación electrónica estaba disponible y no se usó o se usó mal.
- Y se evade con muchísima frecuencia: en un estudio observacional de 5.793 administraciones de medicamentos, el 62,7 % tuvo al menos una maniobra para saltarse el sistema de código de barras, y el riesgo se multiplicaba por más de tres en el turno de la noche. Justo el turno en el que se recogen los cuerpos.
La conclusión de diseño es la que ordena todo este caso de uso: el agente auditor no compite con el lector de códigos; audita si el lector se usó de verdad. Y encaja con el otro hallazgo estructural de la literatura de laboratorio: los errores de etiquetado se detectan típicamente en el paso inmediatamente siguiente al que los originó, y el 96,7 % se corrige antes de que el resultado salga. Quien reconcilia hito a hito, de forma continua, atrapa lo que una auditoría trimestral ya no puede corregir.
Lo que el producto ya sabe hacer: la ecuación de las sillas
El 23 de agosto de 2026 se integró a la rama principal de SFUN la orden de adecuación del espacio, que resuelve un problema aparentemente menor: qué sale a un servicio de cementerio, qué vuelve y qué vuelve dañado. Vale la pena mirarla de cerca, porque es el molde exacto de lo que falta para el cuerpo.
La orden distingue tres comportamientos que no se pueden mezclar. Los retornables —sillas, toldos, cafeteras— salen y tienen que volver. Los consumibles —café, azúcar, vasos— salen y no vuelven: son salida definitiva desde que se entregan. Y los dañados, que son el caso que casi siempre se olvida: un retornable que vuelve roto no reingresa, porque contarlo como devuelto sería mentirle al inventario —la silla existe en el papel y no se puede usar—.
De esa distinción sale una identidad que se verifica sola, y que es todo el mecanismo:
Para un retornable, salió = volvió + dañado + pendiente. Mientras haya pendiente, el servicio no está cerrado del todo.— adecuacion_espacio.py, aplicación de parque cementerio
Dos reglas gobiernan el documento, y las dos importan más que la fórmula. La primera: lo pendiente se calcula, no se teclea —cada vez que se guarda, el sistema recalcula qué falta por volver, así que nadie puede declarar que está todo bien—. La segunda: no se cierra con cosas fuera —cerrar una orden a la que le faltan quince sillas equivale a perderlas, y el sistema lo impide y dice exactamente qué falta—. La orden es un documento formal con estados (Preparando, En servicio, Cerrada), el motor de cálculo es una función pura que no toca la base de datos, y hay una suite de pruebas dedicada a comprobar el caso del toldo que vuelve roto.
Qué datos del ERP intervienen (y en qué estado están de verdad)
Un caso de uso de IA que no empieza por auditar sus propios datos termina siendo una demostración bonita. Esto es lo que hay hoy, verificado contra el código, en los cinco documentos que componen la custodia del cuerpo. Si quieres el detalle operativo de cada uno, está en las guías de gestión de traslados y flota funeraria y de operación de un crematorio.
| Documento | Lo que sí registra | Lo que le falta para cerrar la cadena |
|---|---|---|
| Traslado | Estado (Pendiente, En proceso, Terminado, Cancelado), fecha y hora de inicio y de fin, carroza, conductor, auxiliar, coordinador, proveedor, documento y nombre del fallecido, tipo de origen y de destino. Y guarda historial de cambios. | Sus únicos dos campos obligatorios son “desde” y “hasta”, ambos texto libre. No tiene firma. No tiene sede. No es un documento que se envíe y quede en firme: el cierre es solo cambiar un desplegable, sin fecha de fin obligatoria y sin ninguna validación de que el fin sea posterior al inicio. |
| Cremación | Documento formal que se envía y queda en firme, con historial, 17 verificaciones documentales y —esto sorprende a casi todo el mundo— entrega de cenizas obligatoria: funcionario que entrega, fecha y hora son campos requeridos sin condiciones ni pantallas ocultas. | Se registra quién entrega, no a quién. No hay campo del receptor de las cenizas ni firma de recibido. La única validación propia comprueba que las dos personas autorizantes no sean la misma. |
| Procedimiento tanatopráctico | El eslabón mejor resuelto del sistema: una sección literalmente titulada “FIRMA DE FUNCIONARIO QUE RECIBE”, con campo de firma, más un inventario de 22 ítems —14 prendas y 8 objetos, incluidos marcapasos y prótesis— y registro de objetos devueltos. | La sección de firma viene plegada y el campo de firma no es obligatorio. El patrón correcto existe; lo que falta es exigirlo —y, donde el traspaso cruza la frontera de la empresa, elevarlo a firma digital con validez probatoria. |
| Fallecido | El expediente central, con historial de cambios. | Se nombra con el número de documento: la cédula ES la llave del registro. Y la clase que lo controla no tiene ninguna validación propia. Un dígito mal digitado no produce un error: produce una segunda persona. |
| Velación y exequias | Estados, salas, fechas de inicio y fin, y un proceso automático cada hora que cierra velaciones vencidas con un umbral de 48 horas. | El único umbral horario de todo el sistema vive aquí, y aplica a salas. Para los traslados no existe equivalente. |
Las cuatro preguntas de la auditoría nocturna
El agente no “analiza la operación”. Hace cuatro preguntas concretas, cada una con una definición que un auditor podría discutir y una persona podría corregir. Esa acotación es la que lo vuelve implementable y la que evita que produzca ruido.
- Traslados que siguen abiertos más allá de su ventana razonable. Un traslado en estado Pendiente o En proceso cuya hora de inicio quedó atrás hace más de N horas. Ojo con esto: el umbral en horas hay que definirlo, porque en el sistema hoy no existe —los que hay son de días—. Ponerle un número es una decisión de negocio de la dirección, no un parámetro técnico.
- Secuencias con huecos. Un servicio cuyo destino final aparece cumplido pero al que le falta un eslabón intermedio: cremación en firme sin traslado terminado, velación cerrada sin procedimiento tanatopráctico cuando el tipo de servicio lo exigía, exequias sin cortejo registrado. Es la comparación entre los hitos que el tipo de servicio declara y los hitos que efectivamente ocurrieron.
- Cremaciones cuya entrega de cenizas no tiene destinatario verificable. Como el sistema exige funcionario, fecha y hora pero no receptor, la pregunta útil hoy no es “¿se entregaron?” sino “¿de estas entregas, cuáles no tienen en ninguna parte del expediente constancia de quién recibió?”. Es un hallazgo de expediente incompleto, no de cenizas perdidas, y hay que decirlo así.
- Expedientes de fallecido sospechosamente parecidos. Dos registros con documentos que difieren en un dígito o en una transposición, con apellidos coincidentes y fechas cercanas. Esta es la única de las cuatro que hoy es enteramente nueva: el sistema compara cédulas idénticas, nunca parecidas.
Las cuatro comparten una propiedad que conviene subrayar: ninguna requiere un modelo predictivo. Son reglas de conformidad —comparar lo declarado contra lo ejecutado—, exactamente como la ecuación de las sillas. El modelo de lenguaje no decide si algo está mal; ordena, agrupa, redacta el hallazgo en lenguaje de coordinador de sede y explica por qué esto es más urgente que aquello.
Cómo se arma con MCP, paso a paso
El MCP de SFUN es lo que permite que un agente consulte el ERP respetando los permisos del usuario con el que corre. Para este caso, el recorrido es el siguiente.
- Un usuario propio para el agente, con rol de solo lectura. No el usuario de un coordinador ni una cuenta administrativa. Los permisos de ese usuario son el límite real de lo que el agente puede ver, y deben acotarse a los documentos de la cadena.
- Lectura de los documentos del día y de la ventana abierta. Traslados en estado no terminal, cremaciones enviadas en el período, velaciones y exequias del servicio, procedimientos tanatoprácticos asociados y los expedientes de fallecido creados en la ventana.
- Reconciliación determinista, fuera del modelo. Las cuatro preguntas se resuelven con reglas, no con criterio del modelo. Este es el punto que más se equivoca en el mercado: si el hallazgo depende de que el modelo “se dé cuenta”, el hallazgo no es auditable y no se puede reproducir mañana.
- Priorización y redacción. Aquí sí entra el modelo: ordenar por severidad —lo que la familia está viviendo pesa más que lo administrativo—, agrupar lo que es un mismo incidente visto desde tres documentos y escribir cada caso en dos líneas que un coordinador entienda a las 7 de la mañana sin abrir el sistema.
- Entrega como lista corta. Un tope explícito de casos por sede y por día. No un flujo de alertas: una lista que se pueda terminar de leer.
- Nada de escritura. El agente no cambia estados, no cierra traslados, no corrige cédulas y no fusiona expedientes. Propone; una persona decide y ejecuta en el sistema.
Por qué una lista corta y no un flujo de alertas
Esta es la decisión de diseño que separa un caso de uso que sobrevive de uno que se apaga en dos meses, y es la que más evidencia acumulada tiene en contra de la intuición del gerente que pide “que me avise de todo”.
La referencia más estudiada de fatiga de alertas está en la prescripción electrónica. Un metaanálisis de 16 estudios estima que alrededor del 90 % de las alertas de interacción medicamentosa son descartadas por los médicos —conviene tomarlo como orden de magnitud y no como constante, porque la heterogeneidad entre estudios es total—. Y hay un experimento natural aún más claro: al migrar a un sistema comercial en el que la carga de alertas se multiplicó por seis, la aceptación de las alertas más severas se desplomó del 100 % al 8,4 %. El ruido no solo se ignora: arrastra consigo la capacidad de responder a lo que sí importaba.
La cara positiva está medida con la misma precisión. Comparando más de 71.000 alertas en dos centros, el que las presentaba escalonadas por severidad obtuvo 29 % de cumplimiento frente al 10 % del que no escalonaba, y 100 % de aceptación en las más severas frente al 34 %. Priorizar por consecuencia casi triplica la tasa de acción. Y una revisión sistemática de 39 estudios encontró que, de todas las variantes ensayadas para mejorar la aceptación, la única que la aumentó fue dirigir el aviso al rol que efectivamente puede resolverlo.
El bucle: qué se revisa cada mañana
Un agente de auditoría que no aprende se convierte en un correo que nadie abre. El bucle es la mitad del caso, y es tan importante como la detección.
- Cada mañana, el coordinador marca cada hallazgo. Tres opciones y ninguna más: era real y lo corregí, era real pero no se puede corregir, no era un hallazgo. Esa marca es el insumo de todo lo demás.
- Cada semana, se revisa la tasa de falsos positivos por tipo de pregunta. Si una de las cuatro pasa del umbral que la dirección fije, se ajusta su definición o se apaga. Una pregunta que produce ruido sistemático destruye la credibilidad de las otras tres.
- Cada semana, se revisan los hallazgos “reales pero no corregibles”. Son los más valiosos: cada uno señala un hueco de proceso o de producto, no un descuido. Si el mismo aparece cinco veces, dejó de ser un hallazgo y pasó a ser un requerimiento.
- Cada mes, se mide la cobertura. De los incidentes de custodia que aparecieron por otra vía —queja, auditoría, inspección—, cuántos había detectado el agente antes. Es la única medida honesta de si sirve.
- Cada trimestre, se revisa el umbral de horas. El número inicial es una hipótesis. Con la marca del coordinador acumulada se puede calibrar contra la realidad de cada sede en vez de contra una intuición.
Gobierno y límites: lo que nunca se automatiza
Este caso tiene una línea roja más nítida que cualquier otro del cluster, y conviene escribirla en el acta del comité antes de la primera línea de configuración. El marco general —permisos, trazabilidad y qué queda registrado de lo que hizo la IA— está desarrollado en gobierno de agentes de IA en el ERP funerario.
- Solo lectura, y verificable. Mientras no exista restricción por documento en el servidor, la garantía se construye con un usuario de rol limitado y se audita revisando que no aparezcan cambios atribuidos a ese usuario en el historial de los documentos.
- Datos sensibles del doliente. El hallazgo que llega al coordinador se refiere a documentos y estados, no a la historia clínica ni a la causa de muerte. La causa de muerte es un campo obligatorio del expediente y no tiene por qué salir en un informe de conformidad. En países con norma de datos personales vigente, el tratamiento de datos del fallecido y de los deudos es categoría sensible.
- Nunca hacia la familia. Ningún hallazgo de este agente genera una comunicación al doliente. Es una herramienta de control interno; el contacto con la familia tiene su propio criterio y su propio dueño.
- El hallazgo no es una acusación. Un traslado sin cerrar significa que falta un registro, no que alguien hizo algo mal. Si la lista se usa para evaluar personas, la primera consecuencia predecible es que los estados se cierren a tiempo y en falso.
- Alcance por sede y por rol. Cada coordinador ve su sede. Es más difícil de lo que parece: el documento de traslado no tiene campo de sede, así que hoy el filtro por sede no puede aplicarse sobre traslados. Es otro hueco a cerrar antes de escalar.
Lo que este agente no puede prometer
Un caso de uso que solo enumera beneficios no resiste la primera pregunta difícil del comité. Estos son los tres límites reales, y los tres tienen cifra.
- Ve bastante menos de lo que existe. Cuando se aplicó detección de desviaciones sobre un proceso real de compras y pagos, se encontraron 15 de 31 casos —menos de la mitad— con una tasa de falsos positivos de apenas 0,37 %. Ese es el intercambio de esta familia de herramientas: casi todo lo que señalan es real, y se les escapa buena parte de lo que hay. Se vende como “te ahorra revisar todo”, nunca como “no se te escapa nada”.
- Detectar expedientes parecidos tiene un techo conocido. Contra un patrón de referencia de 30.000 registros revisados a mano, el emparejamiento probabilístico clásico logró un valor predictivo positivo de 0,9995 pero una sensibilidad de 0,64: casi nunca se equivoca al señalar, y deja pasar más o menos un tercio de los duplicados reales. Es coherente con la idea de lista corta, y es incompatible con prometer cobertura total.
- La versión ingenua del método casi no funciona. En detección de anomalías de secuencia, el enfoque intuitivo de “si la conformidad baja de tal umbral, alerta” rinde F1 de 36 % en un banco de pruebas público, porque las distribuciones de casos normales y anómalos se solapan; métodos bien construidos llegan a 88,5 % en datos reales. El mecanismo es homologable; el número no se puede prometer sin haberlo medido en tu propia operación.
Hay además un límite que no es de exactitud sino de honestidad: no existe, hasta donde alcanza la evidencia pública, ningún estudio revisado por pares sobre agentes de IA en solo lectura auditando cadenas de custodia. Lo que sí está probado por separado es la detección de desviaciones de proceso, el efecto de priorizar en vez de alertar y la magnitud del error de custodia en industrias vecinas. Este caso es la composición de tres literaturas maduras aplicada a un sector que no la tiene, no la cita de un estudio que diga que funciona en funerarias. Presentarlo de otro modo sería inventar.
Cómo se mide: línea base y meta
Sin línea base, cualquier resultado se puede contar como éxito. Estos son los cinco indicadores del caso, y todos se pueden medir antes de encender nada.
| Indicador | Cómo se mide | Línea base típica antes de empezar | Meta a 90 días |
|---|---|---|---|
| Traspasos abiertos al cierre del día | Traslados en estado no terminal cuya hora de inicio ya pasó, contados a las 23:59 | Desconocida: nadie la mide hoy. Medirla una semana antes de encender el agente es el primer entregable | Reducción sostenida y, sobre todo, estable: el objetivo no es cero, es que el número no dependa de qué turno estuvo |
| Tiempo hasta el cierre del registro | Horas entre el fin real del traspaso y el momento en que queda registrado | Hoy no se puede calcular: el sistema no guarda la hora comprometida y el fin no es obligatorio | Que exista el dato. Es un prerrequisito, no un resultado |
| Expedientes duplicados detectados y resueltos | Pares de expedientes de fallecido señalados por el agente y confirmados por una persona | Cero detectados, que no es lo mismo que cero existentes | Todos los pares confirmados del período, resueltos con decisión registrada |
| Precisión de la lista | Porcentaje de hallazgos marcados como reales por el coordinador | No aplica | Umbral fijado por la dirección antes de encender; por debajo de él, la pregunta se ajusta o se apaga |
| Cobertura | De los incidentes de custodia detectados por otra vía, porcentaje que el agente había señalado antes | Cero por construcción | Es el único indicador que mide valor real. Los otros cuatro miden que el mecanismo funcione |
Hoja de ruta de adopción
El orden importa: las tres primeras semanas no producen ningún hallazgo, y son las que deciden si el caso sirve.
| Momento | Qué se hace | Criterio para pasar a lo siguiente |
|---|---|---|
| Semana 1 | Medir la línea base sin encender nada: cuántos traspasos quedan abiertos por sede y por turno. Definir con la dirección el umbral de horas de cada tipo de traslado y el tope de casos por lista | Hay un número escrito y un dueño por sede |
| Semanas 2 y 3 | Cerrar el hueco más barato del producto: exigir la firma que ya existe en tanatopraxia y trasladar ese patrón al traslado; agregar receptor de cenizas; agregar sede al traslado | Los datos que el agente va a auditar existen y son obligatorios |
| Mes 1 | Encender solo la primera pregunta —traslados abiertos— en una sede piloto, con lista corta y marca diaria del coordinador | La precisión supera el umbral fijado durante dos semanas seguidas |
| Mes 2 | Sumar secuencias con huecos y entregas sin receptor verificable. Empezar la revisión semanal de hallazgos “reales pero no corregibles” | La lista se lee todos los días y se marca. Si dejó de leerse, el problema es la lista, no el equipo |
| Trimestre 1 | Sumar expedientes parecidos —la más delicada, porque toca identidad—, extender a todas las sedes y recalibrar umbrales con los datos acumulados | La cobertura empieza a ser medible: aparecen incidentes que el agente había señalado antes |
Cinco errores que hacen fracasar este caso
- Empezar por el modelo. El cuello de botella no es la inteligencia: es que el traslado no exige hora de fin, no tiene firma y no tiene sede. Un modelo excelente sobre datos que no se registran produce hallazgos excelentes sobre nada.
- Dejar que el agente cierre lo que encuentra. Convierte un sistema de trazabilidad en una máquina de fabricar constancias sin responsable. Es el único error de esta lista que empeora activamente la situación de partida.
- Confundir la lista con un flujo de alertas. Una lista corta priorizada se lee; un flujo continuo se ignora, y arrastra en su desprestigio a los avisos que sí importaban.
- Prometer detección predictiva. No hay ninguna lógica predictiva en el sistema hoy, y este caso no la necesita: es conformidad, no predicción. Venderlo como anticipación es la vía más rápida a que el comité pierda la confianza en el resto del programa de IA.
- Usar la lista para evaluar personas. Garantiza que los estados se cierren puntualmente y en falso, que es exactamente el resultado contrario al que se buscaba.
Preguntas frecuentes
¿Puede la IA cerrar automáticamente un traslado que quedó abierto por olvido?
Puede, técnicamente, y no debe. Cerrar un traspaso es afirmar que una persona identificable recibió un cuerpo en un momento determinado. Si lo cierra el sistema, el registro dice que hubo una entrega que nadie declaró: parece prueba y no lo es. Un expediente con un hueco visible es preferible a uno completo y falso, porque el hueco se puede investigar. La regla del caso es que el agente propone y una persona ejecuta.
¿Qué se necesita para empezar, si no tenemos nada montado?
Tres cosas, y ninguna es un modelo de IA: que el traslado exija hora de fin y firma de quien recibe; que el traslado tenga sede, para poder dirigir cada hallazgo a su coordinador; y una semana de medición de línea base para saber cuántos traspasos quedan abiertos hoy. Con eso, la primera de las cuatro preguntas ya se puede encender. Sin eso, el agente audita un vacío.
¿El agente ve datos sensibles del fallecido y de la familia?
Ve lo que le permitan los permisos del usuario con el que corre, y por eso ese usuario debe ser propio del agente y de alcance limitado, nunca la cuenta de una persona. El hallazgo que llega al coordinador se refiere a documentos, estados y tiempos: no necesita la causa de muerte ni datos de salud para decir que un traspaso quedó abierto. En los países con norma de protección de datos vigente, los datos del fallecido y de los deudos son categoría sensible, y el principio de minimización aplica también a los informes internos.
¿En qué se diferencia esto de un tablero de pendientes?
En tres cosas. Un tablero se consulta y el agente entrega: si nadie abre la pantalla, el tablero no existe. Un tablero muestra lo que está abierto; el agente busca secuencias con huecos, que es una pregunta que ningún tablero responde. Y un tablero no prioriza ni explica: entrega una lista larga en la que el caso grave y el trivial pesan igual. Dicho esto, un tablero de pendientes es un excelente punto de partida y hoy en SFUN ya existe uno; el caso que lo explota está en la operación del día y el servicio en riesgo, y el marco de control interno en prevención de pérdidas en grupos funerarios.
¿Cuántas horas debe pasar un traslado abierto para que se considere un hallazgo?
Es una decisión de la dirección, no un parámetro técnico, y hay que tomarla explícitamente porque el sistema hoy no tiene ningún umbral horario para traslados: los umbrales existentes son de días, pensados para documentos administrativos. Empieza con un número por tipo de traslado, mídelo contra la marca diaria del coordinador durante un trimestre y recalíbralo. Un umbral demasiado bajo produce ruido; uno demasiado alto convierte el hallazgo en arqueología.
¿Sirve esto en una funeraria de una sola sede?
El mecanismo sirve, pero el retorno no lo justifica igual. En una sede única, con un equipo que se ve todos los días, la reconciliación ocurre de forma informal en el pasillo. El caso empieza a pagar cuando hay varias sedes, turnos que no se cruzan, terceros que ejecutan traslados y un volumen en el que nadie tiene el día entero en la cabeza. Es un caso de grupo funerario.
Referencias
- I. E. Yardley, A. Carson-Stevens y L. J. Donaldson — Serious incidents after death: content analysis of incidents reported to a national database, Journal of the Royal Society of Medicine, 2018;111(2):57-64. Fuente de los 132 incidentes posteriores al fallecimiento, los 25 cuerpos entregados por error a la funeraria y los 9 enterrados o cremados por la familia equivocada: doi:10.1177/0141076817744561.
- Human Tissue Authority (Reino Unido) — Release of the wrong body incidents in the Post Mortem sector, y Código B con el estándar de trazabilidad T1c. Fuente de los 50 incidentes de entrega del cuerpo equivocado entre 2021 y 2024, del mínimo de tres identificadores y de la recomendación de auditorías de proceso periódicas, incluidas no anunciadas: hta.gov.uk.
- W. van der Veen, K. Taxis, H. Wouters, H. Vermeulen, D. W. Bates y P. M. L. A. van den Bemt — Factors associated with workarounds in barcode-assisted medication administration in hospitals, Journal of Clinical Nursing, 2020;29(13-14):2239-2250. Fuente del 62,7 % de eventos con maniobras para saltarse el lector de códigos sobre 5.793 administraciones observadas, y del mayor riesgo en el turno nocturno: doi:10.1111/jocn.15217.
- R. M. Kaufman, A. Dinh, C. S. Cohn y colaboradores (BEST Collaborative) — Electronic patient identification for sample labeling reduces wrong blood in tube errors, Transfusion, 2019;59(3):972-980. Fuente de la caída de 1:3.046 a 1:14.606 con identificación electrónica: doi:10.1111/trf.15102.
- N. M. Dunbar y R. M. Kaufman (BEST Collaborative) — Wrong blood in tube events: an international survey, Transfusion, 2022;62(1):44-50. Fuente de los 331 errores en 36 centros de 11 países y de los 43 casos en que la identificación electrónica estaba disponible y no se usó o se usó mal: doi:10.1111/trf.16716.
- R. E. Nakhleh, M. O. Idowu, R. J. Souers, F. A. Meier y L. G. Bekeris — Mislabeling of cases, specimens, blocks, and slides: a College of American Pathologists study of 136 institutions, Archives of Pathology & Laboratory Medicine, 2011;135(8):969-974. Fuente de que los errores se detectan típicamente en el paso inmediatamente siguiente y del 96,7 % corregido antes de emitir el informe: doi:10.5858/2010-0726-CPR.
- M. A. Makary, J. Epstein, P. J. Pronovost, E. A. Millman, E. C. Hartmann y J. A. Freischlag — Surgical specimen identification errors: a new measure of quality in surgical care, Surgery, 2007;141(4):450-455. Fuente de los 91 errores en 21.351 muestras y del caso del envase vacío, es decir, el hito declarado sin objeto físico detrás: doi:10.1016/j.surg.2006.08.018.
- M. Felisberto, G. dos S. Lima, I. C. Celuppi y colaboradores — revisión sistemática y metaanálisis sobre alertas de interacción medicamentosa, Health Informatics Journal, 2024;30(2). Fuente del ~90 % de alertas descartadas; se cita como orden de magnitud porque la heterogeneidad reportada entre estudios es extrema: doi:10.1177/14604582241263242.
- M. D. Paterno, S. M. Maviglia, P. N. Gorman, D. L. Seger, E. Yoshida, A. C. Seger, D. W. Bates y T. K. Gandhi — Tiering drug-drug interaction alerts by severity increases compliance rates, Journal of the American Medical Informatics Association, 2009;16(1):40-46. Fuente del 29 % frente a 10 % de cumplimiento y del 100 % frente a 34 % de aceptación en las alertas más severas, sobre 71.350 alertas: doi:10.1197/jamia.M2808.
- M. I. Hussain, T. L. Reynolds y K. Zheng — Medication safety alert fatigue may be reduced via interaction design and clinical role tailoring: a systematic review, JAMIA, 2019;26(10):1141-1149. Fuente de que la única intervención que aumentó la aceptación fue dirigir el aviso al rol correcto, y de la advertencia de que las tasas entre estudios no son comparables: doi:10.1093/jamia/ocz095.
- A. Wright y colaboradores — estudio antes-después de la carga de alertas tras migrar a un registro clínico comercial, Journal of General Internal Medicine, 2018. Fuente de la multiplicación por seis de la carga de alertas y de la caída de la aceptación de las más severas del 100 % al 8,4 %: doi:10.1007/s11606-018-4415-9.
- G. Baader y H. Krcmar — Reducing false positives in fraud detection: combining the red flag approach with process mining, International Journal of Accounting Information Systems, 2018;31:1-16. Fuente de los 15 de 31 casos detectados con 0,37 % de falsos positivos: doi:10.1016/j.accinf.2018.03.004.
- S. J. Grannis, J. L. Williams, S. Kasthuri, M. Murray y H. Xu — evaluación de estrategias de emparejamiento de registros de pacientes, JAMIA, 2022;29(8):1409-1415. Fuente del valor predictivo positivo de 0,9995 con sensibilidad de 0,6366 del emparejamiento probabilístico: doi:10.1093/jamia/ocac068.
- A. B. McCoy, A. Wright, M. G. Kahn, J. S. Shapiro, E. V. Bernstam y D. F. Sittig — Matching identifiers in electronic health records: implications for duplicate records and patient safety, BMJ Quality & Safety, 2013;22(3):219-224. Fuente del 16,49 % al 40,66 % de registros con nombre y apellido coincidentes y de su reducción al agregar la fecha de nacimiento: doi:10.1136/bmjqs-2012-001419.
- F. Vitale, M. Pegoraro, W. M. P. van der Aalst y N. Mazzocca — Control-flow anomaly detection in process mining, Knowledge-Based Systems, 2025;310:112970. Fuente del F1 de 88,5 % en datos reales frente al 36,1 % del enfoque de umbral de conformidad en un banco de pruebas público: doi:10.1016/j.knosys.2025.112970.
- U.S. Food and Drug Administration — Drug Supply Chain Security Act Pilot Project Program: Final Program Report, 2023. Fuente del patrón de comparar la información declarada en la transacción contra el código del envase físico, de las discrepancias encontradas y de la conclusión de que, aun con más automatización, seguirá habiendo procesos manuales necesarios: fda.gov.
- Las capacidades y las brechas de SFUN descritas en este artículo se verificaron el 24 de agosto de 2026 contra el código de las aplicaciones de servicios funerarios, control de traslados, parque cementerio y el conector MCP. La orden de adecuación del espacio y su motor de conciliación se integraron a la rama principal el 23 de agosto de 2026.
