Este ateneo trata sobre los CDSS, sus debilidades, y algunas estrategias basadas en la economía conductual para abordar algunas de estas debilidades. Se abordará inicialmente la definición de los CDSS y sus debilidades asociadas. Luego el análisis crítico del primer y segundo artículo, concluyendo con una síntesis de los hallazgos más significativos.

 

¿Qué es un CDSS?

Por un lado tenemos la definición de Eta S. Berner —quien, por cierto, fue entrevistada por el Hospital Italiano durante la pandemia—. Ella define los sistemas de soporte para la toma de decisiones clínicas como sistemas informáticos diseñados para influir en la toma de decisiones clínicas sobre un paciente individual en el momento en que se realiza esa toma de decisión.

Por otro lado, la definición de la AMIA, que expande la de Berner y agrega que estos sistemas proveen conocimientos específicos de la persona —tanto al personal de salud, a los pacientes y al personal de soporte en salud—, que se filtran de manera inteligente y se presentan en el momento apropiado para mejorar la salud tanto de los pacientes como de la población.

 

Las fases evolutivas 

Estas fases no representan el uso cronológico de los sistemas, sino la aparición de diferentes estrategias para la aplicación de los mismos. Tengamos en cuenta que todos estos sistemas de las diferentes fases se siguen utilizando hasta el día de la fecha.

En primer lugar, la fase 1: los sistemas aislados. Son independientes de las historias clínicas electrónicas, lo que facilita compartirlos, pero tienen la debilidad de que los profesionales tienen que acceder al sistema de soporte de manera intencional, iniciar sesión, ingresar los datos del caso y luego leer e interpretar los resultados.

La fase 2 busca integrar estos sistemas a las historias clínicas. Presentan la desventaja de que son más complejos de compartir, ya que pueden presentar formatos propietarios que impiden compartir las bases de conocimiento con otras instituciones.

La fase 3 busca solucionar las dificultades de la fase 2 a través del uso de estándares para representar, codificar y almacenar la información de los CDSS, como puede ser Arden Syntax o GLIF. La desventaja es que estos estándares luego tienen que adaptarse a cada institución, que presenta los datos de los pacientes en una estructura particular.

La fase 4, los modelos de servicio, implementan interfaces de programación de aplicaciones o APIs que permiten centralizar los CDSS y acceder a ellos a través de un servicio.

La fase 5 aprovecha lo que se consigue en la fase 4 y agrega la estandarización de la sintaxis utilizada para compartir la información a través de estándares como HL7 y FHIR. Es justamente acá donde nos encontramos hoy en día la mayoría de los sistemas.

 

Clasificaciones - Taxonomía según producto de salida 

Tenemos por un lado la taxonomía según el producto de salida y por otro la taxonomía según los requerimientos funcionales.

En lo que respecta a la taxonomía según el producto de salida, tenemos las alertas y recordatorios, los tipos más comunes, que se activan en el momento adecuado. Algunos ejemplos son las contraindicaciones droga-problema, las interacciones droga-droga o la aparición de valores críticos de laboratorio. Las alertas son activas —interrumpen el flujo—, mientras que los recordatorios son más pasivos: se muestran sin bloquear la interacción con la historia clínica.

Después tenemos los soportes para la dosis de medicación, que guían al médico en la prescripción farmacológica: ajustes de dosis según edad, peso, función renal o hepática.

Los sistemas expertos son más complejos: combinan características de los pacientes con bases de conocimiento. Por ejemplo, soporte al diagnóstico basado en signos y síntomas, o soporte a la prescripción de antibióticos basado en los antecedentes del paciente y sus antibiogramas.

El display de información relevante no genera recomendaciones, sino que muestra información contextualizada. Ejemplos: infobuttons con links a evidencia dentro del contexto del paciente, o mostrar costos de prácticas o medicaciones.

Los facilitadores de órdenes agilizan la prescripción ofreciendo agrupaciones de estudios o prácticas.

Y el soporte al flujo de trabajo son herramientas integradas en el proceso clínico —no una orden puntual—. Ejemplos: reconciliación de medicación o plantillas estructuradas de documentación, que reducen los errores por omisión y mejoran la consistencia de la información registrada.

 

Taxonomía según requerimientos funcionales 

En lo que respecta a la taxonomía según los requerimientos funcionales, tenemos los triggers o desencadenantes —los elementos que activan el sistema, como el ingreso de una solicitud o la apertura de una historia clínica—; el ingreso de datos —resultados de laboratorio, registros estructurados—; las intervenciones —las acciones que toma el sistema, como una notificación o proveer un valor predeterminado—; y las opciones ofrecidas —las acciones que puede realizar el profesional, como ingresar una prescripción, aplazar el aviso o ignorarlo mediante lo que se conoce como override de la regla—.

 

Debilidades del CDSS - Sutton 2020

En cuanto a las debilidades, nos vamos a basar en un artículo de Sutton que en español se llama «Una visión general de los sistemas de apoyo a la toma de decisiones clínicas: ventajas, riesgos y estrategias para el éxito». (Referencia: Sutton RT et al. An overview of clinical decision support systems: benefits, risks, and strategies for success. npj Digit Med. 2020;3:17). 

Sutton plantea una serie de debilidades. En primer lugar, la fatiga de alertas: el 95% de las alertas son irrelevantes, lo que lleva a una sobreexposición que hace que el médico las ignore de manera sistemática, inclusive las críticas.

En segundo lugar, el impacto en la capacidad de los usuarios: estos sistemas generan dependencia en los profesionales, lo que puede reducir el juicio clínico independiente. Si el sistema falla o no está disponible, el usuario queda desprotegido.

En tercer lugar, la dependencia de conocimientos informáticos: muchos sistemas exigen competencias digitales que no todos los usuarios tienen, lo que puede limitar su adopción y uso efectivo.

En cuarto lugar, el mantenimiento del sistema y su contenido: las reglas clínicas tienen que actualizarse constantemente, y una base de conocimientos desactualizada puede generar alertas incorrectas, erosionando la confianza de los usuarios.

En quinto lugar, mala calidad de los datos e información incorrecta: los CDSS dependen de datos externos —los cargados en las historias clínicas—. Si tenemos listas de medicamentos desactualizadas, alergias mal registradas o datos faltantes, se generan recomendaciones erróneas.

En sexto lugar, flujo de trabajo fragmentado: los sistemas mal integrados o las intervenciones generadas de manera inoportuna pueden interrumpir el flujo clínico.

En séptimo lugar, falta de portabilidad e interoperabilidad: un defecto particularmente de las fases 2 y 3, donde los CDSS no pueden trasladarse entre instituciones ni comunicarse con otros sistemas.

Y por último, las dificultades económicas: muchas instituciones tienen dificultades financieras sostenidas, y la implementación y el mantenimiento de estos sistemas son significativos y muchas veces subestimados.

En particular, para este ateneo nos vamos a enfocar en estas dos debilidades: la fatiga de alertas y alertas inapropiadas, y el flujo de trabajo fragmentado.

 

El primer artículo, que en español se titula «Optimización del diseño de alertas y recordatorios para el apoyo a la toma de decisiones clínicas con MINDSPACE: una revisión sistemática». Este artículo fue publicado por Sarang Hashemi y colaboradores de la Universidad de Monash en Australia, en el año 2024, en el International Journal of Medical Informatics. (Referencia: Hashemi S et al. Sharpening clinical decision support alert and reminder designs with MINDSPACE. Int J Med Inform. 2024;181:105276). 

Este artículo trae a discusión el hecho de que puede existir un uso excesivo de las alertas y recordatorios. Esto, en consecuencia, va a generar interrupciones del flujo de trabajo, frustración de los usuarios y fatiga de alertas. Y como consecuencia de todo esto, estas alertas y recordatorios van a tender a ignorarse o anularse. Y justamente es lo que se trata de abordar en este artículo, a través de la economía conductual, que básicamente estudia la toma de decisiones basadas en comportamiento. Y particularmente lo hace a través de MINDSPACE, que es un marco para el cambio conductual que agrupa nueve factores o efectos distintos que influyen en cómo el humano toma decisiones.

9 efectos de MINDSPACE

El mensajero: nos importa mucho quién transmite la información. No es lo mismo que lo transmita un colega a que lo realice un jefe de servicio.

Los incentivos: respondemos a incentivos de forma predeterminada. Particularmente tenemos aversión a las pérdidas: no queremos perder, siempre queremos ganar.

Las normas sociales: nos influye mucho lo que hacen los demás. Si el 90% de los colegas toman cierta acción, nosotros vamos a querer reproducirla.

Las opciones predeterminadas: nos dejamos llevar por lo que viene ya configurado. Si un sistema propone una opción de forma predeterminada, la mayoría la vamos a aceptar sin cambiar.

La prominencia: nuestra atención se enfoca en lo que es nuevo y relevante. Una alerta visualmente atractiva o distinta al resto nos va a llamar más la atención.

La predisposición: nuestras acciones se ven afectadas por elementos subconscientes. El contexto previo a una decisión es importante.

El afecto: nuestras acciones se ven moldeadas por asociaciones emocionales. No es lo mismo que una alerta nos genere ansiedad a que nos genere calma.

El compromiso: buscamos ser coherentes con nuestras propias promesas. Si dijimos que íbamos a realizar tal acción, vamos a sentir presión para mantenerlo.

Y por último el ego o autoestima: actuamos de formas que nos hacen sentir bien con nosotros mismos.

El segundo estudio, que en español se titula «Eficacia de las intervenciones de nudge no intrusivas en las historias clínicas electrónicas para mejorar la prestación de atención sanitaria en los hospitales: una revisión sistemática». Publicado en julio del 2023 en JAMIA, por Magdalena Raban y su equipo de la Universidad de Macquarie en Australia. (Referencia: Raban MZ et al. Effectiveness of non-interruptive nudge interventions in EHRs to improve care in hospitals: SR. JAMIA. 2023;30(7):1313-1322).

¿Qué es un nudge? - Taxonomía de Münscher

Un nudge, hace referencia a cualquier aspecto de la arquitectura de elección que altera el comportamiento de las personas de forma predecible, sin tener que prohibir ninguna opción disponible.

Raban los separa en tres categorías: 

La primera es la información para la decisión: no se alteran las opciones, solo se presenta la información. Incluye traducir la información, hacer la información visible, y proveer un punto de referencia social.

La segunda es la estructura de la decisión, la más importante y potente en entornos hospitalarios. Modifica el entorno de la elección. Incluye cambiar las opciones predeterminadas, cambiar el esfuerzo asociado a una opción, cambiar el rango o composición de las opciones disponibles, y cambiar las consecuencias de la opción.

La tercera es la asistencia para la decisión: busca cerrar la brecha entre la intención del clínico y el comportamiento que finalmente tiene. Incluye proveer recordatorios y facilitar el compromiso.

 

Aplicabilidad local - Ejemplo Hospital Italiano

Un ejemplo concreto es en el Hospital Italiano: el circuito de solicitud de prácticas quirúrgicas.

Cuando el cirujano solicita una práctica quirúrgica en la historia clínica electrónica, el sistema genera automáticamente la evaluación clínica prequirúrgica, el laboratorio con los estudios correspondientes y, si el paciente tiene más de 40 años, agrega el electrocardiograma —sin que nadie tenga que solicitarlo por separado—.

Esto es exactamente lo que Raban describe: un nudge no interruptivo donde el clínico no recibe ninguna alerta y no necesita recordar qué pedir. El sistema estructura la decisión de forma que la opción correcta es también la de menor esfuerzo.

 

Conclusiones finales 

Primero: cuando un sistema de soporte falla, el problema no suele ser técnico. El sistema se dispara en el momento correcto con la información correcta, pero si el profesional lo cierra igual, eso no es un error —es la cognición humana bajo presión—. Cualquier solución que ignore esto no va a resolver el problema correcto.

Segundo: la evidencia que vimos hoy nos da dos respuestas complementarias. Hashemi nos dice que si vamos a interrumpir al profesional, que esa interrupción valga la pena. Raban nos dice que si podemos no interrumpir, aún mejor. Estas dos opciones no son excluyentes —son capas que se ayudan mutuamente—.

Tercero: estas intervenciones funcionan. Lo que todavía no tenemos es un estándar claro de cómo implementarlas ni cómo clasificarlas de manera reproducible, ni tenemos evidencia suficiente fuera del contexto anglosajón para decir con confianza que funcionan en nuestro campo local.

 

Accedé al video completo a través de este enlace.