Sistemas de soporte a la decisión clínica: qué son y cómo funcionan

Un sistema que avisa tarde o produce demasiados falsos positivos añade carga operativa. No mejora el proceso asistencial.

Los sistemas de soporte a la decisión clínica basados en IA funcionan como una capa de análisis dentro de la historia clínica electrónica y de los sistemas de información hospitalaria. Procesan datos del paciente, aplican reglas o modelos y presentan alertas, verificaciones o sugerencias en el punto de atención. No sustituyen el criterio profesional. Su función es reducir variabilidad, detectar incoherencias y facilitar el acceso a conocimiento clínico actualizado.

La calidad del resultado depende de cinco factores: datos disponibles, calidad de la codificación, interoperabilidad, rendimiento del modelo y diseño de la interfaz. La inteligencia artificial resuelve solo una parte del problema. Si el dato llega incompleto, con retraso o sin contexto clínico, la recomendación también será limitada.

Qué es un sistema de soporte a la decisión clínica

Un CDSS es un componente de software que relaciona información clínica individual con conocimiento médico estructurado. La información puede proceder de la historia clínica electrónica, las órdenes médicas, los resultados de laboratorio, las imágenes, la medicación activa o las notas redactadas por profesionales.

El sistema analiza esa información y devuelve una salida operativa. Las salidas más habituales son:

• Alertas de interacciones entre medicamentos.
• Advertencias relacionadas con alergias registradas.
• Verificación de dosis según edad, peso, función renal u otros parámetros disponibles.
• Recordatorios vinculados a protocolos asistenciales.
• Recomendaciones basadas en guías clínicas.
• Detección de valores anómalos en resultados de laboratorio.
• Priorización de pacientes según riesgo.
• Apoyo al análisis de imágenes médicas.
• Identificación de información relevante en notas clínicas no estructuradas.

La posición del CDSS dentro de la arquitectura es determinante. Puede integrarse en el módulo de órdenes médicas electrónicas, conocido como CPOE, en la historia clínica electrónica o en una plataforma independiente conectada al sistema de información hospitalaria. Cada alternativa modifica la latencia, el contexto disponible y la experiencia del usuario.

Un módulo que aparece dentro del flujo de prescripción puede bloquear una dosis incompatible antes de confirmar la orden. Una aplicación externa que requiere copiar datos y consultar otra pantalla introduce más fricción. El contenido clínico puede ser equivalente. El rendimiento operativo no.

Un CDSS eficaz no es el que genera más alertas. Es el que presenta la alerta correcta, al profesional correcto y en el momento correcto.

La evaluación debe separar dos conceptos. El primero es la precisión técnica del modelo o de la regla. El segundo es la utilidad clínica de la salida. Una alerta puede ser correcta desde el punto de vista matemático y, aun así, carecer de valor si el profesional ya conoce el problema, si aparece fuera de contexto o si interrumpe una tarea de bajo riesgo.

Reglas, modelos y sistemas híbridos

Los primeros sistemas expertos clínicos se basaban en reglas explícitas. Su lógica podía expresarse mediante condiciones predefinidas: si el paciente presenta una determinada alergia y se prescribe un fármaco relacionado, se genera una advertencia. Estos sistemas son auditables. El hospital puede revisar la regla, modificarla y documentar su comportamiento.

La limitación está en la cobertura. Las reglas solo detectan escenarios previstos. No interpretan bien la variabilidad del lenguaje clínico ni las relaciones complejas entre múltiples variables.

Los sistemas basados en aprendizaje automático añaden capacidad para identificar patrones en grandes volúmenes de datos. Pueden utilizarse para clasificación de riesgo, predicción de deterioro o priorización de casos. Su rendimiento depende del conjunto de entrenamiento, de la calidad de las etiquetas y de la similitud entre los datos de desarrollo y los datos reales del hospital.

La combinación de ambos enfoques suele ser más controlable:

El sistema híbrido no elimina la necesidad de supervisión. La amplía. Las reglas necesitan mantenimiento de contenido. Los modelos necesitan vigilancia de rendimiento. En ambos casos, el hospital debe conservar un registro de versiones, cambios, incidencias y responsables.

Evolución técnica: de los sistemas expertos a la inteligencia artificial

La evolución de los CDSS puede dividirse en tres etapas operativas. La primera corresponde a los sistemas expertos de reglas. La segunda incorpora bases de datos clínicas, terminologías normalizadas y motores de inferencia más amplios. La tercera añade aprendizaje automático, procesamiento del lenguaje natural y visión computarizada.

El procesamiento del lenguaje natural permite analizar notas clínicas desestructuradas. Esta capacidad tiene valor porque una parte relevante del contexto asistencial no se introduce mediante campos estructurados. Diagnósticos diferenciales, antecedentes, observaciones y evolución pueden estar escritos en texto libre.

El problema es la ambigüedad. Una nota puede describir un antecedente, una sospecha, una negación o una información pendiente de confirmar. El sistema debe distinguir entre una condición presente y una condición mencionada como descartada. También debe gestionar abreviaturas, errores tipográficos, unidades y terminología local.

La visión computarizada se utiliza para analizar imágenes médicas. Su integración requiere una conexión estable con los sistemas de imagen, además de un mecanismo claro para presentar el resultado. El modelo puede señalar una región sospechosa o asignar una probabilidad. La decisión clínica continúa dependiendo del contexto, de la calidad de la imagen y de la revisión profesional.

La inteligencia artificial añade capacidad de análisis. No garantiza una recomendación válida. Para valorar el comportamiento de un modelo, el hospital debe observar al menos:

• Sensibilidad y especificidad para el escenario clínico definido.
• Tasa de falsos positivos y falsos negativos.
• Latencia de procesamiento.
• Porcentaje de casos sin respuesta por falta de datos.
• Estabilidad del rendimiento entre servicios y grupos de pacientes.
• Frecuencia de recalibración.
• Tasa de aceptación o rechazo de las recomendaciones.
• Incidencias producidas después de la actualización del modelo.

La tasa de aceptación no equivale a precisión. Un profesional puede aceptar una recomendación por falta de tiempo. También puede rechazarla aunque sea correcta porque el sistema no muestra el razonamiento o porque la recomendación llega fuera de momento.

Cómo se incorpora la IA en la toma de decisiones médicas

La integración de IA en la toma de decisiones médicas debe definirse como un flujo controlado. El sistema recibe datos, procesa variables, calcula una salida, la presenta y registra la interacción. Cada fase produce puntos de fallo diferentes.

1. Captura de datos. El sistema obtiene información de la historia clínica, del laboratorio, de la farmacia, de dispositivos o de notas clínicas. La ausencia de un dato no debe interpretarse automáticamente como ausencia de una condición.

2. Normalización. Los diagnósticos, medicamentos, unidades y resultados deben utilizar codificaciones consistentes. Los valores expresados con unidades incompatibles pueden alterar el resultado.

3. Cálculo. El motor aplica reglas, modelos o ambos. Debe conservar la versión del algoritmo y los parámetros relevantes para reconstruir la decisión.

4. Presentación. La interfaz muestra el riesgo, la recomendación y el contexto. Una salida sin explicación operativa obliga al profesional a realizar una segunda interpretación.

5. Respuesta profesional. El usuario acepta, descarta, modifica o ignora la sugerencia. Esa acción debe quedar registrada sin convertirla en una aprobación automática del resultado.

6. Auditoría. El hospital compara el comportamiento del sistema con los resultados clínicos y con la práctica real. El análisis debe incluir errores de integración, no solo errores del modelo.

La automatización de protocolos médicos funciona mejor cuando el protocolo está definido de forma precisa. En cambio, los escenarios con información incompleta o alta variabilidad clínica requieren una presentación prudente. El software de ayuda al diagnóstico clínico no debe ocultar el grado de incertidumbre.

Arquitectura e integración con CPOE, EHR e HIS

Un CDSS no opera de forma aislada. Necesita conectarse con las aplicaciones que registran y ejecutan la actividad asistencial.

El EHR concentra la información longitudinal del paciente. El HIS gestiona procesos hospitalarios más amplios, como admisión, camas, facturación, farmacia, laboratorio y actividad quirúrgica. El CPOE registra las órdenes médicas electrónicas. El CDSS consulta estos sistemas y devuelve resultados al punto de atención.

La arquitectura debe resolver cuatro problemas técnicos.

1. Disponibilidad del contexto clínico

Una alerta de dosis requiere más que el nombre del medicamento. Puede necesitar edad, peso, función renal, vía de administración, frecuencia y medicación concomitante. Si alguno de estos campos no está disponible o no está actualizado, la regla opera con contexto parcial.

La integración debe definir qué fuente tiene prioridad. El peso puede existir en varias aplicaciones con fechas distintas. La alergia puede estar registrada como texto libre, como código estructurado o en ambos formatos. Sin una política de precedencia, el motor puede utilizar información antigua.

2. Latencia

La latencia admisible depende del caso de uso. Una alerta durante la prescripción exige una respuesta casi inmediata. Un análisis nocturno de riesgo poblacional puede ejecutarse por lotes. El hospital no debe utilizar la misma arquitectura para ambos escenarios.

La latencia total incluye:

• Tiempo de extracción del dato.
• Conversión y validación del formato.
• Comunicación con el motor de decisión.
• Ejecución de la regla o del modelo.
• Devolución de la respuesta.
• Renderizado en la interfaz clínica.

Una red lenta o una aplicación con múltiples llamadas secuenciales puede degradar el flujo aunque el modelo responda rápido. El rendimiento debe medirse de extremo a extremo.

3. Trazabilidad

Cada recomendación debe poder relacionarse con los datos que la originaron, la versión del contenido clínico y la respuesta del profesional. Sin esta trazabilidad, la investigación de un incidente se vuelve incompleta.

El registro técnico debería incluir, según el caso:

• Identificador del paciente o seudónimo operativo.
• Fecha y hora del evento.
• Datos de entrada utilizados.
• Regla o modelo activado.
• Versión del algoritmo.
• Resultado generado.
• Usuario o rol que recibió la alerta.
• Acción realizada.
• Errores de comunicación o datos ausentes.

La protección de datos médicos exige limitar el acceso y conservar solo la información necesaria para la finalidad definida. La trazabilidad no justifica una recopilación ilimitada.

4. Continuidad operativa

Un CDSS no puede convertirse en un punto único de fallo. Si el motor no responde, la prescripción y la atención deben continuar mediante un procedimiento alternativo. El sistema debe definir qué alertas pueden omitirse temporalmente y cuáles requieren un mecanismo de contingencia.

La disponibilidad del servicio, el tiempo de recuperación y la consistencia de las colas de mensajes son métricas de infraestructura. También lo es la capacidad de evitar duplicados cuando una orden se reintenta después de una interrupción.

Interoperabilidad: el papel de HL7 FHIR

La interoperabilidad determina si los datos pueden circular entre sistemas sin perder significado. No consiste únicamente en conectar dos aplicaciones. También exige que ambas interpreten de la misma manera un paciente, una medicación, una alergia, una observación o una orden.

HL7 FHIR, sigla de Recursos Rápidos de Interoperabilidad en Salud, organiza la información clínica en recursos normalizados. Entre los recursos utilizados en integraciones sanitarias se encuentran el paciente, la condición clínica, la medicación, la alergia, la observación, la solicitud de servicio y el resultado.

Su valor para los CDSS está en la normalización del intercambio. Un motor puede consultar datos procedentes de varios sistemas mediante estructuras previsibles. Esto reduce la dependencia de interfaces propietarias y facilita la escalabilidad.

La adopción de FHIR no resuelve por sí sola todos los problemas. Un recurso puede estar técnicamente bien formado y contener información incompleta. También pueden existir diferencias en terminologías, perfiles, extensiones y políticas de identificación.

La integración debe comprobar de forma secuencial:

1. Identificación del paciente. El mismo paciente debe conservar una correspondencia fiable entre aplicaciones. Los errores de identidad invalidan cualquier recomendación posterior.

2. Mapeo de terminologías. Medicamentos, diagnósticos y pruebas deben asociarse a códigos coherentes. El texto libre no puede ser la única fuente para una decisión de alto riesgo.

3. Unidades y valores. El motor debe distinguir miligramos, gramos, mililitros, concentraciones y rangos de referencia. La conversión automática necesita reglas verificables.

4. Marca temporal. Un resultado clínico sin fecha o con una fecha interpretada incorrectamente puede provocar una alerta fuera de contexto.

5. Estado del recurso. Una medicación suspendida no debe tratarse como activa. Una orden propuesta no equivale a una orden ejecutada.

6. Gestión de errores. El sistema debe informar de campos ausentes, respuestas incompletas y fallos de autenticación. Una respuesta vacía no debe presentarse como un resultado negativo.

En entornos con múltiples proveedores, la interoperabilidad también afecta al mantenimiento. Si cada módulo utiliza un formato distinto, cualquier cambio en el CDSS exige adaptadores adicionales. Aumentan la complejidad, la latencia y el coste de soporte.

FHIR mejora el intercambio de información. No corrige datos mal codificados, identidades duplicadas ni procesos clínicos mal definidos.

La implementación debe comenzar por los casos de uso con mayor estabilidad semántica. Las alertas de alergias, interacciones y dosis suelen tener datos más estructurados que el análisis de notas clínicas. Esto permite validar la conectividad antes de introducir modelos con mayor incertidumbre.

Marco regulatorio europeo y MDR 2017/745

En la Unión Europea, el software que asiste en el diagnóstico o el tratamiento puede clasificarse como producto sanitario. La clasificación no depende solo de que el proveedor utilice inteligencia artificial. Depende de la finalidad prevista y del impacto de la salida sobre las decisiones clínicas.

El Reglamento Europeo de Productos Sanitarios MDR 2017/745 establece requisitos específicos para el software sanitario. Cuando un CDSS entra en el ámbito del reglamento, el fabricante debe documentar su finalidad, gestión de riesgos, evaluación clínica, ciclo de vida, seguridad y rendimiento. También puede ser necesario obtener certificación y marcado CE mediante el procedimiento aplicable.

El hospital no debe asumir que una herramienta de recomendación queda fuera del marco regulatorio por presentarse como apoyo informativo. La descripción funcional del producto es relevante. Un sistema que solo organiza documentos no tiene necesariamente el mismo tratamiento que otro que recomienda una pauta, clasifica un riesgo o influye en una decisión terapéutica.

La evaluación regulatoria debe revisar:

• Finalidad prevista declarada por el fabricante.
• Tipo de salida generada por el software.
• Consecuencia clínica de aceptar o ignorar la recomendación.
• Clasificación del producto sanitario.
• Evidencia clínica disponible.
• Procedimiento de gestión de riesgos.
• Control de versiones y modificaciones.
• Validación del rendimiento en el entorno previsto.
• Ciberseguridad y protección de la información.
• Vigilancia posterior a la comercialización.

La actualización de un modelo puede modificar su comportamiento. Por esta razón, el control de cambios debe formar parte del gobierno del sistema. No es suficiente con registrar que se ha instalado una nueva versión. Debe quedar documentado qué datos, parámetros, reglas o componentes han cambiado y qué pruebas se han ejecutado.

La certificación tampoco sustituye la validación local. Un modelo autorizado puede comportarse de forma diferente cuando se conecta a un hospital con otra población, otros protocolos, otras codificaciones y otra distribución de datos. El despliegue necesita pruebas técnicas y clínicas en condiciones reales, con supervisión y posibilidad de reversión.

Casos de uso clínico y operativo

Alertas de medicación

La prescripción electrónica es uno de los escenarios más extendidos para los CDSS. El sistema puede comprobar interacciones, alergias, duplicidades, dosis y restricciones asociadas a la función renal.

El riesgo principal es la fatiga por alertas. Si el sistema presenta advertencias de baja relevancia con la misma prioridad que una interacción grave, el usuario aprende a ignorarlas. La solución no consiste en eliminar todas las alertas. Consiste en estratificar la severidad, reducir duplicidades y mostrar el motivo de la recomendación.

Una alerta bien diseñada debe indicar:

• Qué orden ha activado el aviso.
• Qué dato clínico se ha utilizado.
• Qué riesgo se ha detectado.
• Qué acción propone el sistema.
• Qué alternativas permite el protocolo.
• Si el profesional puede justificar una excepción.

El bloqueo automático requiere un umbral más exigente que el aviso informativo. Un bloqueo mal configurado puede retrasar tratamientos y generar atajos operativos. El hospital debe medir los desbloqueos, las anulaciones y los eventos relacionados.

Análisis de notas clínicas

El procesamiento del lenguaje natural puede localizar síntomas, antecedentes, tratamientos previos y factores de riesgo en texto libre. Este uso reduce la dependencia de la introducción estructurada, pero añade ambigüedad.

El motor debe reconocer negaciones, temporalidad y grado de certeza. No es equivalente mencionar una alergia como antecedente confirmado, como sospecha o como información descartada. La validación necesita un conjunto de notas representativo del hospital, con variaciones de estilo y terminología.

La salida debe presentarse como apoyo a la revisión. No debe convertir automáticamente una interpretación del texto en un diagnóstico confirmado ni modificar la historia clínica sin intervención autorizada.

Categorización en tiempo real

Los CDSS también pueden clasificar pacientes ingresados según variables clínicas y operativas. El Hospital Clínic de Barcelona evaluó el sistema COVID-19 Control Center, conocido como C3, para categorizar en tiempo real a pacientes ingresados y orientar decisiones asistenciales.

Este tipo de sistema exige actualización continua. Un riesgo calculado con datos antiguos pierde valor. La arquitectura debe definir la frecuencia de actualización, los eventos que disparan un nuevo cálculo y el tratamiento de datos ausentes.

La categorización puede apoyar la priorización de recursos, pero no debe ocultar los criterios que la generan. El profesional necesita conocer las variables principales y la vigencia del resultado.

Apoyo al diagnóstico mediante imágenes

La visión computarizada puede señalar hallazgos en imágenes médicas. La integración suele requerir conexión con los sistemas de archivo y comunicación de imágenes, identificación correcta del estudio y devolución del resultado al entorno de trabajo radiológico.

La tasa de error debe analizarse por tipo de estudio y población. Un rendimiento global puede ocultar fallos en subgrupos concretos. También debe medirse el tiempo añadido al proceso. Si el resultado llega después de cerrar el informe, su utilidad disminuye.

Cómo integrar un CDSS en un hospital

La implantación debe seguir una secuencia controlada. El error habitual consiste en adquirir primero la herramienta y definir después el proceso. La infraestructura y la finalidad clínica deben concretarse antes de seleccionar el producto.

Paso 1. Delimitar el problema

El hospital debe formular el caso de uso en términos operativos. No basta con solicitar inteligencia artificial para mejorar la seguridad. La definición debe indicar qué decisión se quiere apoyar, en qué servicio, con qué datos y en qué momento del flujo.

Un caso bien delimitado puede ser la verificación de dosis en pacientes con función renal registrada. Un caso ambiguo sería automatizar la toma de decisiones médicas sin especificar la salida ni el responsable de la decisión.

Paso 2. Revisar la calidad de los datos

La evaluación debe identificar fuentes, propietarios, frecuencia de actualización y tasa de datos ausentes. También debe localizar duplicados, errores de unidad y conflictos entre aplicaciones.

Un modelo no puede compensar una historia clínica electrónica con registros incompletos. La limpieza de datos forma parte del proyecto y no debe tratarse como una tarea posterior.

Paso 3. Diseñar la integración

El equipo técnico debe definir interfaces, autenticación, identificación de pacientes, terminologías y gestión de errores. HL7 FHIR puede facilitar el intercambio, pero el proyecto debe concretar los perfiles y recursos que se utilizarán.

La integración debe probarse con datos de laboratorio, medicación, alergias, diagnósticos y órdenes. También con escenarios negativos: paciente no encontrado, recurso incompleto, servicio no disponible y respuesta duplicada.

Paso 4. Validar el rendimiento

La validación debe incluir datos históricos y pruebas prospectivas. El hospital debe comparar las recomendaciones con una referencia clínica definida y analizar falsos positivos, falsos negativos y casos sin respuesta.

El rendimiento técnico debe medirse junto con el clínico. Una recomendación precisa que llega con una latencia incompatible con el flujo de prescripción no cumple el objetivo operativo.

Paso 5. Ejecutar un despliegue limitado

El primer despliegue debe concentrarse en un servicio o proceso. Esto permite observar la carga de alertas, la comprensión de la interfaz, los rechazos y los fallos de interoperabilidad.

La puesta en producción necesita un mecanismo de retirada. Si el sistema altera el flujo o genera resultados inconsistentes, el hospital debe poder desactivarlo sin interrumpir la actividad asistencial principal.

Paso 6. Supervisar y recalibrar

El seguimiento no termina con la instalación. El hospital debe revisar el comportamiento por servicio, tipo de paciente y versión del modelo. También debe controlar los cambios en protocolos, medicamentos, codificaciones y población atendida.

La deriva del modelo aparece cuando cambia la relación entre los datos de entrada y el resultado clínico. Puede deberse a nuevas prácticas, modificaciones en el registro o cambios en la prevalencia de una condición. Sin monitorización, la pérdida de rendimiento puede pasar inadvertida.

Errores técnicos frecuentes

Los fallos de implantación suelen producirse en la interfaz entre tecnología y proceso asistencial. Los más habituales son los siguientes:

• Usar datos no actualizados. La recomendación se calcula con una medicación, un peso o un resultado de laboratorio que ya no representa la situación del paciente.
• Confundir ausencia con resultado negativo. Si una alergia no está registrada, el sistema no debe asumir que no existe.
• Duplicar alertas. Varios módulos pueden avisar sobre el mismo riesgo. El usuario recibe mensajes repetidos y reduce su nivel de atención.
• Ocultar la incertidumbre. Una probabilidad o clasificación se muestra como una afirmación clínica definitiva.
• Integrar fuera del flujo de trabajo. El profesional debe abrir otra aplicación, copiar datos o repetir la identificación del paciente.
• No registrar la respuesta. Sin datos de aceptación, rechazo o modificación, no se puede evaluar la utilidad real.
• Actualizar sin validación. Un cambio de versión modifica reglas o modelos sin una prueba clínica equivalente.
• Prescindir del plan de contingencia. Una caída del motor paraliza una función que debería tener un procedimiento alternativo.
• Medir solo la precisión. El análisis ignora latencia, tasa de alertas, carga cognitiva y efecto sobre el proceso.
• Tratar la certificación como garantía universal. El cumplimiento regulatorio no demuestra que el sistema esté bien integrado en un hospital concreto.

La reducción de errores médicos con IA depende de la gestión de estos puntos. La tecnología puede detectar inconsistencias. No puede corregir una política de datos deficiente, una interfaz mal diseñada o un protocolo clínico contradictorio.

Qué debe evaluar el hospital antes de seleccionar la solución

La selección debe combinar criterios clínicos, técnicos, regulatorios y operativos. Las promesas de precisión general no sustituyen las pruebas con datos y flujos del propio centro.

La evaluación debe cubrir:

• Compatibilidad con el EHR, el HIS y el CPOE existentes.
• Soporte de HL7 FHIR y de las terminologías utilizadas.
• Latencia de respuesta en los casos interactivos.
• Capacidad de funcionamiento en tiempo real y por lotes.
• Registro completo de eventos y versiones.
• Gestión de usuarios, permisos y segregación de funciones.
• Cifrado, autenticación y controles de acceso.
• Mecanismos de actualización y reversión.
• Evidencia clínica relacionada con la finalidad prevista.
• Clasificación conforme al MDR 2017/745 cuando corresponda.
• Posibilidad de configurar prioridades y umbrales.
• Herramientas para medir falsas alertas y alertas ignoradas.
• Capacidad de exportar datos de auditoría.
• Disponibilidad, recuperación ante fallos y soporte técnico.
• Transparencia sobre las fuentes de conocimiento y los cambios del modelo.

El proveedor debe explicar qué ocurre cuando faltan datos, cuando el servicio no responde o cuando el modelo no puede clasificar un caso. La respuesta no puede limitarse a una pantalla genérica de error. El proceso debe indicar cómo continúa la actividad clínica y cómo queda registrado el incidente.

Conclusión: el valor está en la integración, no en el algoritmo

Los sistemas de soporte a la decisión clínica basados en IA son componentes de infraestructura asistencial. Su rendimiento depende de la calidad del dato, la interoperabilidad, la latencia, la trazabilidad y el control regulatorio.

La evolución desde los sistemas expertos basados en reglas hacia el procesamiento del lenguaje natural, la visión computarizada y el aprendizaje automático amplía los casos de uso. También amplía la superficie de riesgo. Cada nueva capacidad exige validación, vigilancia y una definición precisa de responsabilidades.

Un CDSS bien integrado puede mejorar la consistencia de la prescripción, facilitar la aplicación de protocolos y reducir omisiones en contextos concretos. No sustituye al profesional. No convierte datos incompletos en conocimiento fiable. No corrige por sí solo una arquitectura hospitalaria fragmentada.

La decisión técnica debe cerrarse con una prueba local, métricas de rendimiento y un plan de retirada. Si el hospital no puede medir la tasa de error, la latencia, las alertas ignoradas y el comportamiento tras cada actualización, todavía no controla el sistema. Solo lo está utilizando.