Salud · Excelencia Operacional TI
Confiabilidad tecnológica en hospitales inteligentes
Por qué conectar es fácil y sostener es la verdadera capacidad
— "La torre de monitoreo nueva ya está integrada al EHR."
— ¿Y qué hacemos con los pacientes si el lunes a las 3 a.m. el EHR no responde?
Esa segunda pregunta rara vez tiene respuesta escrita. Y es la que define si un hospital es realmente inteligente o solo está digitalizado. Porque conectar dispositivos, plataformas y datos clínicos es la parte fácil. Lo difícil —y lo que casi nadie presupuesta— es sostener la confiabilidad tecnológica en hospitales cuando esos sistemas, las personas que los operan y los procesos que los rodean se ponen bajo estrés.
En diciembre de 2025, la Clínica Dávila en Chile sufrió un ataque de ransomware del grupo Devman: 250 GB exfiltrados, fichas de pacientes con VIH publicadas en la dark web. El vector de entrada fue una VPN con usuario y contraseña idénticos. No fue una falla de hardware sofisticado. Fue una falla de capacidad organizacional. Y ese es el corazón de este artículo.
Qué está pasando: la conversación ya cambió en 2026
En la HIMSS26 Europe (Copenhague, mayo de 2026), una encuesta de Black Book a los asistentes arrojó un resultado que descolocó a más de un proveedor: la prioridad de inversión subreportada no es la IA, es la continuidad digital del cuidado. Los líderes hospitalarios europeos declararon que la recuperabilidad cibernética debe evaluarse como una capacidad de continuidad asistencial, no como una función de seguridad TI ni de cumplimiento. El Healthcare Cybersecurity Forum dedicó un día completo a ransomware, continuidad, zero trust, seguridad de dispositivos médicos y tecnología operacional.
El dato que debería estar en cada directorio: según un estudio de la American Economic Association, la mortalidad intrahospitalaria de pacientes ya admitidos sube entre 34% y 38% durante la fase inicial de un ataque de ransomware. El sector salud concentró el 22% de los ataques divulgados en 2025, con un alza interanual cercana al 50%. La caída del sistema dejó de ser un problema de TI. Es un evento de seguridad del paciente.
<header class="hospital-header">
<div class="hospital-brand">SKALLING · SALUD</div>
<span class="hospital-header-tag">Confiabilidad IT/OT · Hospitales inteligentes</span>
<div class="hospital-header-title">Tres capas que sostienen la confiabilidad de un hospital inteligente</div>
<p class="hospital-header-sub">Conectar dispositivos y datos es la parte fácil. La confiabilidad es una propiedad que emerge cuando personas, procesos y sistemas se sostienen entre sí — incluso bajo falla o ataque.</p>
</header>
<section class="hospital-layers-section">
<div class="hospital-section-title">Personas · Procesos · Sistemas</div>
<p class="hospital-section-sub">Saltarse una capa rompe las otras dos. La confiabilidad no se compra: se construye en las tres a la vez.</p>
<article class="hospital-layer hospital-layer-people">
<div class="hospital-layer-head">
<div class="hospital-layer-icon">👥</div>
<div>
<div class="hospital-layer-name">Personas</div>
<div class="hospital-layer-tag">Identidad y conducta</div>
</div>
</div>
<ul class="hospital-layer-points">
<li><strong>MFA real</strong> — el 80% de los ataques en salud son centrados en identidad.</li>
<li><strong>Gobernanza del acceso de proveedores</strong> — cerrar los túneles VPN abiertos años por el fabricante.</li>
<li><strong>Equipos clínicos entrenados</strong> — saber qué hacer cuando la pantalla se apaga.</li>
</ul>
</article>
<article class="hospital-layer hospital-layer-process">
<div class="hospital-layer-head">
<div class="hospital-layer-icon">🔄</div>
<div>
<div class="hospital-layer-name">Procesos</div>
<div class="hospital-layer-tag">Hospital mínimo viable</div>
</div>
</div>
<ul class="hospital-layer-points">
<li><strong>30–50 apps críticas</strong> identificadas: sin ellas no hay atención.</li>
<li><strong>Procedimientos de caída</strong> en papel, ensayados (pizarras, formularios, tableros).</li>
<li><strong>RTO / RPO explícitos</strong> — ej. Franciscan Health fija RTO de 72 h.</li>
</ul>
</article>
<article class="hospital-layer hospital-layer-systems">
<div class="hospital-layer-head">
<div class="hospital-layer-icon">🖧</div>
<div>
<div class="hospital-layer-name">Sistemas</div>
<div class="hospital-layer-tag">Arquitectura para fallar</div>
</div>
</div>
<ul class="hospital-layer-points">
<li><strong>Microsegmentación</strong> — contener el radio de explosión; empezar por OT fijo.</li>
<li><strong>Telemetría liviana</strong> donde el EDR no corre (dispositivos embebidos).</li>
<li><strong>Priorizar por explotabilidad real</strong>, no por CVSS en bruto.</li>
</ul>
</article>
<div class="hospital-layers-note">
<div class="hospital-layers-note-icon">🛡️</div>
<p>Marco de referencia: <strong>IEC 80001-1:2021</strong> (safety, efectividad, security) + <strong>IEC 62443</strong> (zonas) + <strong>IEC 81001-5-1</strong> (ciclo de vida del software de salud). Confiabilidad clínica y ciberseguridad ya son el mismo problema.</p>
</div>
</section>
<section class="hospital-shift-section">
<div class="hospital-section-title">El cambio mental que lo ordena todo</div>
<p class="hospital-section-sub">No basta con que el servidor responda. Importa que el equipo de salud pueda completar el flujo de cuidado.</p>
<div class="hospital-shift-grid">
<div class="hospital-shift-card hospital-shift-old">
<div class="hospital-shift-card-title">Uptime de infraestructura</div>
<p>"El servidor responde a los chequeos." Métrica técnica que no garantiza atención segura.</p>
</div>
<div class="hospital-shift-arrow">→</div>
<div class="hospital-shift-card hospital-shift-new">
<div class="hospital-shift-card-title">Disponibilidad clínica</div>
<p>SLO atados al flujo de cuidado: latencia de ficha, tasa de orden exitosa, error budgets por criticidad. Chaos engineering acotado y postmortems sin culpa.</p>
</div>
</div>
</section>
<section class="hospital-keymetric-section">
<div class="hospital-keymetric">
<div class="hospital-keymetric-number">+34–38%</div>
<div class="hospital-keymetric-text">
<strong>Alza de mortalidad intrahospitalaria</strong> en pacientes ya admitidos durante la fase inicial de un ataque de ransomware (American Economic Association). La caída del sistema no es un problema de TI: es un evento de seguridad del paciente.
</div>
</div>
</section>
<footer class="hospital-footer">
<div class="hospital-footer-row">
<div class="hospital-footer-text">
<strong>Eventos 2026:</strong> HIMSS26 Europe — la continuidad digital del cuidado, no el hype de IA, es prioridad board-level.<br>
<strong>Casos LATAM:</strong> Clínica Dávila (Devman, dic-2025), ISP (jun-2025), FONASA (2023). Marco Chile: Ley 21.668, Ley 21.180, Ley Marco de Ciberseguridad (OIV / ANCI), ISO 27001:2022.
</div>
<div class="hospital-footer-brand">
<div class="hospital-footer-brand-name">SKALLING</div>
<div class="hospital-footer-brand-tag">NotConsulting · Salud</div>
<div class="hospital-footer-cta">skalling.com/contacto</div>
</div>
</div>
</footer>Qué es la confiabilidad IT/OT en un hospital inteligente
La confiabilidad tecnológica en hospitales es la capacidad de mantener disponibles, seguros y efectivos los sistemas clínicos y los dispositivos conectados —incluso bajo falla, ataque o sobrecarga— de forma que la atención al paciente no se interrumpa. No es un producto. Es una propiedad emergente de tres capas que tienen que sostenerse entre sí: personas, procesos y sistemas.
La complejidad nace de la convergencia IT/OT. El mundo IT son los EHR, los portales, la nube, las APIs de interoperabilidad. El mundo OT —tecnología operacional— son las bombas de infusión, los monitores de signos vitales, los equipos de imagenología, los sistemas de climatización de pabellones, los tubos neumáticos, el control de accesos. A esto se suma el IoMT (Internet of Medical Things): miles de dispositivos conectados que, en muchos hospitales, viven en una red plana, sin separación, corriendo sistemas operativos que el fabricante ya no parcha.
El estándar internacional que ordena este terreno es IEC 80001-1:2021, que establece la gestión de riesgo para redes TI que incorporan dispositivos médicos, alineado con ISO 31000, alrededor de tres propiedades clave: seguridad (safety), efectividad y seguridad de la información (security). Lo complementan IEC 62443 (segmentación por zonas, heredada del mundo industrial) e IEC 81001-5-1 (ciclo de vida del software de salud). El punto no es memorizar siglas. Es entender que confiabilidad clínica y ciberseguridad ya son el mismo problema.
<header class="arch-header">
<div class="arch-brand">SKALLING · SALUD</div>
<span class="arch-header-tag">Arquitectura IT/OT · Referencia</span>
<div class="arch-header-title">Anatomía de un hospital inteligente: zonas IT/OT y ruta de capacidades sostenibles</div>
<p class="arch-header-sub">De la administración al dispositivo de cabecera. Microsegmentar por zonas contiene el radio de explosión de un incidente y protege la continuidad asistencial.</p>
</header>
<section class="arch-zones-section">
<div class="arch-section-title">Cinco zonas, un solo objetivo: que la atención no se detenga</div>
<p class="arch-section-sub">Modelo de segmentación adaptado del enfoque Purdue al entorno clínico. Empezar a cercar por los activos fijos de mayor riesgo.</p>
<div class="arch-zone arch-z-admin">
<div class="arch-zone-level">5</div>
<div class="arch-zone-body"><h4>Administrativo / Enterprise</h4><p>Correo, ERP, portales, ofimática. Red corporativa general — el origen más común de movimiento lateral.</p></div>
<div class="arch-zone-risk">Aislar de lo clínico</div>
</div>
<div class="arch-zone arch-z-clinical">
<div class="arch-zone-level">4</div>
<div class="arch-zone-body"><h4>Sistemas clínicos (IT)</h4><p>EHR, PACS, LIS, APIs de interoperabilidad (HL7 FHIR), nube clínica. El corazón del flujo de cuidado.</p></div>
<div class="arch-zone-risk">SLO clínicos</div>
</div>
<div class="arch-zone arch-z-iomt">
<div class="arch-zone-level">3</div>
<div class="arch-zone-body"><h4>IoMT — dispositivos conectados</h4><p>Monitores, bombas de infusión, telemetría, imagenología. Miles de equipos, muchos sin parche del fabricante.</p></div>
<div class="arch-zone-risk">Telemetría liviana</div>
</div>
<div class="arch-zone arch-z-ot">
<div class="arch-zone-level">2</div>
<div class="arch-zone-body"><h4>OT — infraestructura física</h4><p>Climatización de pabellones, tubos neumáticos, ascensores, control de accesos, energía. Fijos y fáciles de cercar.</p></div>
<div class="arch-zone-risk">Empezar aquí</div>
</div>
<div class="arch-zone arch-z-bedside">
<div class="arch-zone-level">1</div>
<div class="arch-zone-body"><h4>Cabecera / Punto de cuidado</h4><p>Dispositivos de soporte vital y diagnóstico junto al paciente. Falla aquí = riesgo clínico inmediato.</p></div>
<div class="arch-zone-risk">Tolerancia cero</div>
</div>
<div class="arch-seg-note">
<strong>Regla de oro:</strong> clasificar cada activo conectado en "soporta directamente la atención del paciente" vs "no". Esa pregunta reordena las prioridades de segmentación, parchado y monitoreo. No se protege —ni se hace confiable— lo que no se ha mapeado.
</div>
</section>
<section class="arch-route-section">
<div class="arch-section-title">Ruta para incorporar capacidades sin romper la confiabilidad</div>
<p class="arch-section-sub">Entregar valor nuevo mientras se sostiene lo que ya mantiene la atención en marcha.</p>
<div class="arch-route-grid">
<div class="arch-step">
<div class="arch-step-num">1</div>
<h4>Inventariar y clasificar</h4>
<p>Mapear cada activo y ordenarlo por impacto en la atención antes de conectar nada nuevo.</p>
</div>
<div class="arch-step">
<div class="arch-step-num">2</div>
<h4>Hospital mínimo viable</h4>
<p>Definir las 30-50 apps críticas, sus RTO/RPO y procedimientos de caída en papel.</p>
</div>
<div class="arch-step">
<div class="arch-step-num">3</div>
<h4>Ensayar (game day)</h4>
<p>Chaos engineering acotado + simulacro con personal clínico real. Probar, no asumir.</p>
</div>
<div class="arch-step">
<div class="arch-step-num">4</div>
<h4>Capacidad, no proyecto</h4>
<p>Equipo permanente, gobernanza IT/OT compartida, postmortems sin culpa.</p>
</div>
</div>
</section>
<section class="arch-close-section">
<div class="arch-close-card">
<div class="arch-close-icon">🏥</div>
<p>La diferencia entre un hospital <strong>inteligente</strong> y uno <strong>solo conectado</strong> rara vez es el catálogo de dispositivos. Es si las personas, los procesos y los sistemas se sostienen entre sí cuando todo lo demás falla.</p>
</div>
</section>
<footer class="arch-footer">
<div class="arch-footer-row">
<div class="arch-footer-text">
Estándares: IEC 80001-1:2021 · IEC 62443 · IEC 81001-5-1 · ISO 27001:2022 · HL7 FHIR. Marco Chile: Ley 21.668 (interoperabilidad fichas), Ley 21.180 (Transformación Digital del Estado), Ley Marco de Ciberseguridad (OIV / ANCI). Referencia para CIO, CISO, CMIO e ingeniería biomédica.
</div>
<div class="arch-footer-brand">
<div class="arch-footer-brand-name">SKALLING</div>
<div class="arch-footer-brand-tag">NotConsulting · Salud</div>
<div class="arch-footer-cta">skalling.com/contacto</div>
</div>
</div>
</footer>El error de fondo: comprar tecnología sin construir capacidad
Hay un patrón que se repite en las redes hospitalarias de LATAM. Se adquiere una plataforma —telemetría, un nuevo PACS, una torre de monitoreo, un módulo de IA— y se integra al EHR en tiempo récord. La foto de prensa es excelente. Seis meses después, nadie sabe quién monitorea ese sistema fuera de horario, no existe un procedimiento de caída, y el dispositivo quedó colgado de la misma red que la administración.
La trampa es confundir creación de valor con captura sostenible de valor. Integrar entrega un beneficio visible una vez. Sostener la confiabilidad entrega un beneficio invisible todos los días: el día que no hubo incidente, el examen que no se retrasó, la cirugía que no se postergó. Esa asimetría hace que lo primero se financie y lo segundo se posponga. Hasta que el lunes a las 3 a.m. la pregunta del comité clínico se vuelve real.
Esta lógica no es exclusiva de la salud. Ya la exploramos en otro sector intensivo en activos: cuando la confiabilidad digital se trata como una capacidad organizacional —y no como una compra puntual— la diferencia no es técnica, es estructural.
Las tres capas que sostienen la confiabilidad
Incorporar capacidades nuevas sin degradar la confiabilidad exige trabajar las tres capas a la vez. Saltarse una rompe las otras dos.
Personas
El 80% de los ataques en salud son centrados en identidad. El caso Dávila entró por una credencial débil. La capa de personas no se resuelve con un curso anual de phishing: requiere autenticación multifactor real, gobernanza del acceso remoto de proveedores (esos túneles abiertos años por el fabricante son la puerta trasera más común), y equipos clínicos que sepan qué hacer cuando la pantalla se apaga. La confiabilidad es una conducta antes que una tecnología.
Procesos
Aquí vive el concepto más subestimado: el hospital mínimo viable. Toda red hospitalaria debería identificar las 30 a 50 aplicaciones sin las cuales no puede dar atención, y diseñar para mantenerlas vivas. Eso implica procedimientos de caída documentados y ensayados —pizarras, formularios en papel, tableros manuales de seguimiento—, objetivos explícitos de tiempo de recuperación (RTO) y de pérdida de datos tolerable (RPO). Franciscan Health, por ejemplo, fija un RTO de 72 horas. Lo crítico no es el número: es que exista, esté escrito y se haya practicado en un game day real, no solo en un PowerPoint.
Sistemas
La arquitectura tiene que asumir que algo va a fallar. El control técnico que más recomiendan los CISO hospitalarios en 2026 es la microsegmentación: aislar los dispositivos médicos en zonas, separar lo clínico de lo administrativo, contener el "radio de explosión" de un incidente. Como los activos OT fijos —climatización, ascensores, tubos neumáticos— son más fáciles de cercar que los dispositivos clínicos móviles, conviene empezar por ahí. Y dado que muchos dispositivos embebidos no admiten un agente EDR, se sustituye por telemetría liviana: uso de CPU, procesos nuevos, cambios de configuración. Detalle clave para priorizar: rastrear explotabilidad real, no el puntaje CVSS en bruto.
De "uptime" a disponibilidad clínica
El cambio mental más importante es dejar de medir que el servidor responde y empezar a medir que el equipo de salud puede completar el flujo de cuidado con seguridad. Eso es disponibilidad clínica, y se gestiona con prácticas de Site Reliability Engineering adaptadas al riesgo sanitario.
- SLO clínicos, no solo de infraestructura. Tiempo de envío de una orden médica, latencia de acceso a la ficha, tasa de escritura exitosa. Métricas atadas al flujo de cuidado, no al CPU.
- Error budgets por criticidad. No todos los sistemas merecen el mismo objetivo. Clasificar servicios por impacto clínico directo y asignar metas de confiabilidad diferenciadas reduce la fatiga de alertas.
- Chaos engineering acotado y ético. Inyectar fallas controladas —caída de identidad, latencia de base de datos, timeout de integración— en ambientes que espejean producción, con datos sintéticos, aprobaciones y plan de rollback. El objetivo no es romper: es probar que el monitoreo, los runbooks y la recuperación funcionan de verdad.
- Postmortems sin culpa. La confiabilidad no se construye con héroes que apagan incendios, sino con sistemas que aprenden de cada incidente.
Cuando una red hospitalaria empieza a hablar este lenguaje, la incorporación de capacidades nuevas —incluida la IA agéntica que ya está entrando a la operación clínica— deja de ser una apuesta y pasa a ser una decisión gobernada, con niveles de autonomía y supervisión definidos.
El mapa regulatorio: Chile como caso, LATAM como tendencia
Chile ofrece el laboratorio más nítido de la región. Tres leyes empujan en la misma dirección:
- Ley N°21.668 — interoperabilidad de las fichas clínicas: obliga a compartir datos resguardando confidencialidad e integridad.
- Ley N°21.180 — Transformación Digital del Estado: expediente electrónico e interoperabilidad bajo estándares abiertos y seguros.
- Ley Marco de Ciberseguridad — crea la figura de Organizaciones de Importancia Vital (OIV), entre las que caen los actores críticos de salud, que deben demostrar capacidades reforzadas de gestión de riesgo y respuesta a incidentes, supervisadas por la Agencia Nacional de Ciberseguridad (ANCI).
La tensión es clara: la ley exige interoperar, pero interoperar sin una capa homogénea de seguridad y gobierno es lo que dejó expuestos al ISP en 2025 (paralizando exámenes críticos de VIH y hepatitis) y a FONASA en 2023 (≈25 servidores comprometidos vía la VPN de un proveedor). En este marco, ISO 27001:2022 se consolida como el piso mínimo para acreditar gobernanza. El resto de LATAM avanza por la misma ruta, con velocidades distintas: la interoperabilidad sin confiabilidad por diseño es una contradicción que la regulación está empezando a sancionar.
Cómo incorporar capacidades sin romper la confiabilidad
Tres movimientos concretos para una red hospitalaria que quiere entregar valor nuevo sin comprometer lo que ya sostiene la atención:
- Inventariar y clasificar antes de conectar. Cada activo conectado, ordenado en dos categorías: ¿soporta directamente la atención del paciente o no? Esa sola pregunta reordena las prioridades de segmentación, parchado y monitoreo. No se puede proteger —ni hacer confiable— lo que no se ha mapeado.
- Definir el hospital mínimo viable y ensayarlo. Las 30-50 aplicaciones críticas, sus RTO/RPO, sus procedimientos de caída en papel, probados en un game day con personal clínico real. La resiliencia se mide en continuidad del cuidado durante la crisis, no en la diapositiva del plan.
- Tratar la confiabilidad como capacidad, no como proyecto. Equipo permanente, SLO clínicos, postmortems sin culpa, gobernanza IT/OT compartida —seguridad define la política, operación clínica ejecuta la remediación—. Lo que se financia como proyecto termina cuando se acaba el presupuesto; lo que se construye como capacidad sostiene la operación todos los días.
La pregunta del comité clínico de 2026 no es "¿qué tecnología compramos?". Es "¿estamos construyendo la capacidad de operarla con confiabilidad cuando todo lo demás falle?". La diferencia entre un hospital inteligente y uno meramente conectado rara vez es el catálogo de dispositivos. Es si las personas, los procesos y los sistemas se sostienen entre sí.
Si tu organización está conectando más rápido de lo que profesionaliza su confiabilidad —y la mayoría lo está—, probablemente valga la pena conversar. No sobre qué plataforma comprar, sino sobre cómo construir la capacidad que la vuelve sostenible.
Fuentes:
HIMSS26 Europe / Black Book — Digital Care Continuity como prioridad board-level
American Economic Association — alza de mortalidad 34-38% en fase inicial de ransomware (vía SC Media)
IEC 80001-1:2021 — Gestión de riesgo para redes TI con dispositivos médicos · IEC 62443 · IEC 81001-5-1
HealthSystemCIO — OT blind spots y microsegmentación en hospitales
HealthTech Magazine — Hospital mínimo viable, RTO/RPO y resiliencia clínica
trendTIC — ¿Interoperar sin seguridad? Casos Dávila, ISP y FONASA en Chile
Interferencia — Ransomware Clínica Dávila (Devman, dic 2025)
Marco legal Chile: Ley N°21.668 (interoperabilidad fichas clínicas), Ley N°21.180 (Transformación Digital del Estado), Ley Marco de Ciberseguridad (OIV / ANCI), ISO 27001:2022.