CDSS en Enfermería

Qué es un CDSS (y qué no es)

Un CDSS —sistema de soporte a la decisión clínica, por sus siglas en inglés— es un programa que cruza los datos concretos de un paciente con una base de conocimiento y devuelve una recomendación al profesional. Eso es todo. No hace falta que lleve inteligencia artificial: una regla que avisa de una interacción entre dos fármacos es un CDSS, y lleva décadas funcionando.

Lo digo de entrada porque la palabra suena a novedad y no lo es. Si trabajas en un hospital con historia clínica electrónica, ya convives con varios CDSS aunque nadie los llame así. La escala de Braden que calcula el riesgo de úlceras por presión, el aviso que salta al prescribir una dosis fuera de rango, la alerta de alergia, el cálculo automático de una escala de deterioro a partir de las constantes que acabas de registrar. Todos encajan en la definición.

Lo que sí ha cambiado es la generación nueva: sistemas que aprenden de datos históricos en vez de seguir reglas escritas por alguien. Y ese cambio trae una consecuencia que conviene tener clara desde el principio: una regla se puede leer; un modelo entrenado, no siempre. Cuando el sistema dice «riesgo alto», la pregunta de por qué lo dice tiene respuesta fácil en el primer caso y difícil en el segundo.

Los CDSS que ya usas sin llamarlos así

Merece la pena mirar los que ya tienes delante, porque enseñan más que cualquier definición.

La escala de Braden. Cuando la registras, el sistema calcula una puntuación y en muchos hospitales dispara un plan de cuidados. Es un CDSS de manual: datos del paciente, base de conocimiento, recomendación. Y arrastra el problema clásico de estas herramientas: la puntuación depende de cómo valores tú las subescalas, así que el sistema es exactamente tan bueno como el registro que lo alimenta.

Las alertas de medicación. El caso donde mejor se ve lo que sale mal cuando un CDSS se diseña sin pensar en quien lo recibe. Volveré sobre ellas.

Las escalas de deterioro. Aquí es donde la enfermería aporta la señal, aunque la herramienta rara vez lo reconozca: las constantes las tomas tú, con la frecuencia que tú decides, y esa frecuencia ya es información clínica.

Fíjate en lo que tienen en común los tres. La enfermera no es la destinataria del sistema: es su fuente de datos. El CDSS se alimenta de tu registro y devuelve la recomendación, a veces a otra persona. Esa asimetría explica bastante de por qué estas herramientas se reciben con desconfianza en las plantas.

La pregunta que casi nadie hace: ¿está validado aquí?

En 2021, un equipo de la Universidad de Michigan publicó en JAMA Internal Medicine la validación externa del modelo de sepsis de Epic, uno de los CDSS predictivos más extendidos del mundo, integrado en cientos de hospitales. Analizaron 27.697 pacientes y 38.455 hospitalizaciones.

Los resultados, que conviene leer despacio:

• AUC de 0,63 (IC 95%: 0,62-0,64). Traducido: puestos delante un paciente que desarrolló sepsis y otro que no, el sistema acertaba cuál era cuál 63 veces de cada 100. Un poco mejor que echarlo a suertes.
• Sensibilidad del 33%. Se le escapaban dos de cada tres casos.
• Valor predictivo positivo del 12%. De cada 100 alertas, 88 eran falsas.
• Alertaba en el 18% de todas las hospitalizaciones, y solo identificó el 7% de los casos que los clínicos no habían detectado ya por su cuenta.

Ese último dato es el que más me interesa. El sistema no aportaba casi nada que el ojo clínico no viera antes, pero generaba una alerta en casi una de cada cinco hospitalizaciones. Todo el coste, casi ningún beneficio.

Y aquí está la lección que quiero que te lleves de este artículo: el rendimiento de un CDSS no es una propiedad del programa, es una propiedad del programa en una población concreta. Cambia el hospital, cambia el perfil de pacientes, cambian los criterios de registro, y el rendimiento se mueve. A veces mucho.

Por eso, cuando alguien te presente un sistema con una cifra de acierto brillante, la pregunta útil no es cuánto acierta. Es dónde se midió eso, con qué pacientes, y si alguien lo ha vuelto a medir aquí.

La fatiga de alertas no es un problema de actitud

Las revisiones sistemáticas sobre alertas de medicación arrojan tasas de rechazo —override— que van del 46% al 96% según el entorno y el tipo de alerta. En muchos servicios se ignoran entre nueve y noventa y cinco de cada cien alertas que salen en pantalla.

Es fácil leer ese dato como negligencia. Sería un error. La literatura muestra algo más incómodo: cuantas más alertas recibe un profesional, menos probable es que acepte la siguiente, incluida la que sí importaba. No es desidia, es cómo funciona la atención humana cuando se la satura. Un sistema que interrumpe cuarenta veces por turno está formando activamente a su usuario para ignorarlo.

La consecuencia práctica es que una alerta tiene un coste, y ese coste no lo paga quien la configura sino quien la recibe. Cuando alguien propone «vamos a añadir un aviso para esto», la pregunta que casi nunca se hace es cuántos avisos hay ya en esa pantalla.

CONCERN: cuando la señal es la documentación de enfermería

Frente a ese panorama quiero contar el caso contrario, porque existe y porque es el que más directamente nos toca.

El sistema CONCERN —desarrollado entre la Universidad de Columbia y el Brigham and Women's Hospital— parte de una idea sencilla y, mirándola desde una planta, bastante evidente: cuando una enfermera se preocupa por un paciente, cambia lo que hace antes de escribir que está preocupada. Toma las constantes más a menudo. Escribe más notas. Administra medicación a demanda, o la retira. Vigila más.

CONCERN no lee un diagnóstico: lee esos patrones de vigilancia en la historia clínica —frecuencia de constantes y de comentarios sobre ellas, medicación PRN administrada y retirada, frecuencia y contenido de las notas— agregados en ventanas de doce horas, y los convierte en un semáforo de riesgo de deterioro.

Los resultados se publicaron en Nature Medicine en 2025, y vienen de un ensayo pragmático con aleatorización por conglomerados: 74 unidades clínicas repartidas entre dos sistemas sanitarios y 60.893 encuentros hospitalarios a lo largo de un año.

• Riesgo de muerte un 35,6% menor en las unidades con el sistema (razón de riesgo ajustada 0,644; IC 95%: 0,532-0,778).
• Estancia un 11,2% más corta.

Dicho lo cual, la letra pequeña también toca aquí: es un ensayo, en dos sistemas sanitarios estadounidenses, con sus formas de registrar. Lo que hace bueno a CONCERN no es que sea trasladable tal cual, es lo que demuestra: que la vigilancia enfermera, que hasta ahora se perdía como ruido en la historia clínica, es una señal clínica medible y con valor pronóstico. Eso sí viaja.

Qué dice la norma hoy (y qué no dice todavía)

Esta parte cambió hace poco y circula mucha información caducada, así que conviene precisarla.

El Reglamento Europeo de IA clasifica como de alto riesgo buena parte de los sistemas de IA sanitarios, y su artículo 14 exige supervisión humana efectiva. Pero el paquete Ómnibus retrasó la aplicación de esas obligaciones: al 2 de diciembre de 2027 para el alto riesgo por uso, y al 2 de agosto de 2028 para el alto riesgo por producto, que es donde caen los productos sanitarios. Muchos resúmenes siguen diciendo agosto de 2026: ya no es así. Lo desarrollo en detalle en mi informe sobre el AI Act después del Ómnibus.

Sí están vigentes las prohibiciones del artículo 5 y las obligaciones de transparencia del artículo 50.

Ahora bien, para el trabajo diario en un hospital, la fecha del AI Act es casi irrelevante. Lo que regula hoy a un CDSS que se comercializa con finalidad clínica es el MDR, el reglamento de productos sanitarios, que no se movió ni un día. Si el sistema que te presentan tiene marcado CE como producto sanitario, esa es la conversación. Si no lo tiene, la pregunta sobre qué es exactamente y con qué finalidad se usa es todavía más pertinente.

Siete preguntas antes de que un CDSS entre en tu unidad

Esto es lo que yo pregunto cuando me traen uno. No hace falta ser informático para hacerlas, y ninguna es hostil: son las que un proveedor serio espera.

1. ¿Dónde se validó, y con qué pacientes?

   Si la respuesta es «en la literatura» o «en Estados Unidos», tienes el caso del modelo de sepsis delante. Pide la población, no la cifra.

2. ¿Cuál es el valor predictivo positivo esperable aquí?

   No la sensibilidad, que es la que enseñan siempre. El VPP es el que te dice cuántas de las alertas que vas a ver serán falsas, y depende de cuánta enfermedad haya en tu población.

3. ¿Cuántas alertas va a generar al día en esta unidad?

   Que lo estimen antes de instalarlo. Si no saben responder, no han pensado en quien las recibe.

4. ¿Qué pasa cuando la rechazo?

   ¿Se registra el motivo? ¿Alguien lo lee? Un override que no se analiza es información clínica que se tira a la basura todos los días.

5. ¿De qué datos se alimenta, y quién los registra?

   Casi siempre la respuesta incluye «de la valoración de enfermería». Conviene decirlo en voz alta en la reunión donde se decide comprarlo.

6. ¿Quién revisa su rendimiento dentro de un año?

   Los modelos se degradan cuando cambia la población o la forma de registrar. Un CDSS sin plan de seguimiento es un CDSS que envejecerá sin que nadie se entere.

7. ¿Tiene marcado CE como producto sanitario?

   Y si no lo tiene, con qué finalidad declarada se está usando. La respuesta cambia quién responde de un error.

Conclusión: el CDSS no sustituye el criterio, lo pone a prueba

De los dos casos que he contado, el que fracasó tenía mejor tecnología y más despliegue. El que funcionó partía de una idea sobre el trabajo clínico: que la preocupación de una enfermera, aunque no llegue a escribirse, deja rastro.

Esa me parece la lección que aguanta el paso del tiempo. Un CDSS no vale por lo que predice, sino por lo que añade a lo que ya se sabía —y el modelo de sepsis de Epic aportaba un 7% sobre el ojo clínico mientras interrumpía en una de cada cinco hospitalizaciones—.

Para quien trabaja en una planta, esto se traduce en algo bastante concreto: tu criterio no es lo que el sistema viene a sustituir, es la vara con la que se mide si el sistema sirve. Cuando rechazas una alerta con motivo, estás generando exactamente el dato que hace falta para saber si esa alerta debería existir. Que ese dato se pierda o se aproveche no es un problema técnico: es una decisión de quien implanta la herramienta.

Si en tu unidad va a entrar uno, la pregunta con la que yo empezaría no es «¿funciona?». Es «¿qué va a pasar el día que le diga que no?».