Ventana de mantenimiento en un sistema clínico 24x7: acuerdo con los servicios, contingencia, plan por pasos, vuelta atrás y validación

Qué vas a conseguir

Parar la historia clínica electrónica (HCE) de un hospital para una actualización sin que la atención se resienta: una ventana acordada con quien trabaja esa noche, un procedimiento de contingencia que la planta conoce, un plan con horas y puntos de decisión, una vuelta atrás probada y una validación hecha por profesionales clínicos antes de dar el sistema por bueno. Y saber qué hacer cuando la ventana se alarga y urgencias necesita el sistema ya.

Antes de empezar

• La plataforma de ejemplo: la aplicación HCE en servidores Red Hat Enterprise Linux, la base de datos en Oracle y el acceso de los usuarios por Citrix. Lo mismo vale con otros componentes.
• El cambio probado en preproducción, con su tiempo medido y la vuelta atrás ensayada, como en la guía de entornos de prueba.
• Los nombres de quienes deciden: responsable funcional de la HCE, dirección de enfermería, jefe de la guardia médica, DBA, proveedor y el responsable de IT de guardia.
• El inventario de lo que depende de la HCE: laboratorio, imagen, farmacia, admisión, la capa de integración y las impresoras de etiquetas y pulseras.

1. La ventana, acordada con los servicios clínicos

En un hospital no hay hora sin pacientes. Hay horas con menos actividad y servicios que se pueden preparar:

• La hora: de madrugada entre semana suele ser la menos mala (por ejemplo, de 2:00 a 5:00 un martes). Evita los cambios de turno de enfermería, la preparación de la dosis unitaria de farmacia y las extracciones de primera hora del laboratorio.
• Con quién: la dirección de enfermería y las supervisoras de guardia de esa noche, el jefe de la guardia médica y urgencias, el laboratorio, radiología, farmacia y admisión. Cada uno dice qué le pasa sin sistema y qué necesita antes.
• La duración máxima: se acuerda el corte total que el hospital acepta y una hora límite. Si a esa hora no está, se vuelve atrás.
• El calendario: con tres o cuatro semanas de antelación, sin coincidir con otros cambios, festivos, una auditoría o una semana de pico asistencial (gripe, puentes).

Que las supervisoras de guardia sepan la fecha antes que nadie: son quienes organizan la planta esa noche.

2. El cambio y su aprobación

La petición de cambio llega al comité de cambios (CAB) completa:

1. Qué se cambia, por qué y qué partes de la HCE toca.
2. Resultado de las pruebas en preproducción, con el visto bueno del responsable funcional.
3. Plan por pasos con horas (sección 5) y el criterio y el plan de vuelta atrás (sección 6).
4. Procedimiento de contingencia y la lista de servicios avisados.
5. Usuarios clave que validarán, y a qué hora estarán disponibles.

3. El procedimiento de contingencia

Durante la parada el hospital sigue funcionando sin HCE. Eso se prepara:

• Formularios en papel por servicio: órdenes médicas, registro de constantes, administración de medicación, peticiones al laboratorio y a radiología, ingreso y alta. Cada unidad tiene su carpeta de contingencia y sabe dónde está.
• Visor de solo lectura (o de contingencia): una copia de consulta de los datos clínicos, en un servidor aparte o en un PC por unidad, que se actualiza periódicamente y sigue disponible cuando la HCE está parada. Comprueba la tarde anterior que se ha refrescado y abre en cada unidad.
• Listados impresos antes de la parada, en cada unidad: pacientes ingresados con cama, alergias, medicación activa y su plan de administración para las horas de la ventana. Una hora antes, no la tarde anterior: así reflejan los ingresos de la noche.
• Identificación y etiquetas: admisión y urgencias tienen pulseras y etiquetas de contingencia, o un número provisional para los pacientes que lleguen durante la parada.
• La vuelta: lo registrado en papel se pasa a la HCE después. Quién lo hace, en qué orden (primero medicación y órdenes) y hasta cuándo, está escrito antes de la ventana.

Si el visor de contingencia o los listados no están listos a la hora prevista, la ventana no empieza. Es el primer punto de decisión.

4. La comunicación: antes, durante y después

• Una sola persona de IT habla con las supervisoras durante la ventana. Los técnicos trabajan; el coordinador informa.
• El aviso en Citrix no debe sustituir a la llamada: a las dos de la madrugada nadie lee un mensaje en pantalla.

5. El plan por pasos, con horas y puntos de decisión

Los pasos técnicos que hacen posible la vuelta atrás, antes de tocar nada:

›SELECT name, log_mode, flashback_on FROM v$database;NAME      LOG_MODE     FLASHBACK_ON--------- ------------ ------------------HCEPRO    ARCHIVELOG   NO›CREATE RESTORE POINT antes_rfc0518 GUARANTEE FLASHBACK DATABASE;Restore point created.›SELECT name, guarantee_flashback_database, time FROM v$restore_point;NAME           GUA TIME-------------- --- ------------------------------ANTES_RFC0518  YES 17-NOV-26 01.34.12.000000000 AM

›Set-BrokerApplication -Name "HCE Produccion" -Enabled $false›Get-BrokerApplication -Name "HCE Produccion" | Select-Object Name, EnabledName           Enabled----           -------HCE Produccion   False

• El punto de restauración garantizado necesita la base en ARCHIVELOG y espacio en el área de recuperación (FRA). El DBA calcula cuánto generará la actualización.
• Deshabilitar la aplicación en Citrix impide nuevas sesiones; las abiertas se cierran con aviso tras la llamada a las supervisoras.
• Las integraciones de entrada (laboratorio, admisión) se paran de forma que los mensajes se encolen, no se pierdan. Se apunta la profundidad de cada cola antes y después.

6. La vuelta atrás

• El criterio, escrito antes: si a la hora límite (03:30) las comprobaciones técnicas no han terminado bien, se vuelve atrás. No se negocia a las 03:29.
• El plan, ensayado en preproducción con su tiempo: parar la aplicación, volver la base de datos al punto de restauración y la aplicación a su versión anterior (paquetes, ficheros o la instantánea de las máquinas virtuales de aplicación).

›SHUTDOWN IMMEDIATE›STARTUP MOUNT›FLASHBACK DATABASE TO RESTORE POINT antes_rfc0518;Flashback complete.›ALTER DATABASE OPEN RESETLOGS;Database altered.

• Tras la vuelta atrás se valida igual que tras el cambio: el sistema antiguo también tiene que funcionar antes de abrirlo.
• Con el visto bueno definitivo, el DBA borra el punto de restauración (DROP RESTORE POINT antes_rfc0518;): si se olvida, llena la FRA en unos días.

7. Validación con usuarios clave y vigilancia posterior

Los usuarios clave son profesionales clínicos (una enfermera, un médico de guardia, alguien de admisión y del laboratorio) que conocen los circuitos y están citados a la hora prevista. Con un paciente de pruebas en producción, siguen un guion corto:

1. Buscar el paciente y abrir su historia; ver alergias y episodios anteriores.
2. Registrar constantes y una administración de medicación.
3. Prescribir y comprobar que la orden llega a farmacia.
4. Pedir una analítica y comprobar que llega al laboratorio; recibir un resultado de prueba.
5. Imprimir una etiqueta y una pulsera.
6. Cada paso, firmado con nombre y hora en la hoja de validación.

Las comprobaciones técnicas van antes, en paralelo:

›systemctl is-active hce-app hce-integracionactiveactive›curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://hce.contoso.local/health200 0.412s›journalctl -u hce-app --since "02:30" -p err --no-pager | tail -n 5-- No entries --

• Después de abrir: las colas de integración se vacían, los tiempos de respuesta se comparan con los medidos antes del cambio y la monitorización vuelve a avisar. El silencio de la ventana caduca a su hora, como en la guía de monitorización y alarmas.
• IT de guardia refuerza las primeras horas del turno de mañana: es cuando todo el hospital entra a la vez.

8. El ticket: "la ventana se alarga y urgencias necesita el sistema"

Martes, 03:40. La actualización de la base de datos debía acabar a las 03:15 y va por el 80 %. La supervisora de guardia llama: urgencias tiene cinco pacientes en espera, el visor de contingencia no muestra las pruebas de un paciente que ingresó a las 02:30 y el jefe de la guardia pregunta cuándo vuelve el sistema.

1. Es el punto de decisión 2, con diez minutos de retraso. El coordinador reúne en una llamada al proveedor, al DBA, al responsable de IT de guardia y al jefe de la guardia médica (o a quien la dirección designó como responsable clínico de la ventana).
2. Los hechos, no las impresiones: cuánto queda según el proveedor y con qué fiabilidad; cuánto tarda la vuelta atrás (35 minutos ensayados); si la vuelta atrás sigue siendo posible desde donde está la actualización.
3. Las opciones:

• Seguir: si quedan 15 minutos y la estimación es sólida, el sistema nuevo podría estar en 45 minutos con validación.
• Volver atrás: el sistema antiguo, en unos 50 minutos con validación, y el cambio para otra ventana.

1. Quién decide: IT y el proveedor dicen qué es posible y cuánto tarda; el responsable clínico decide si el hospital aguanta ese tiempo en contingencia. Si la estimación del proveedor ya ha fallado una vez, la opción por defecto es la que estaba escrita: volver atrás.
2. Mientras tanto, la contingencia se refuerza: el paciente de urgencias se atiende con el papel y una llamada directa al laboratorio para sus resultados. Nadie espera al sistema para tratar a un paciente.
3. Comunicar la decisión a la supervisora con una hora concreta ("a las 04:35, sistema disponible") y llamar si cambia. Una hora que se incumple dos veces vale menos que ninguna.
4. Después: el registro en papel se pasa a la HCE, empezando por urgencias. En la revisión del cambio, por qué el paso tardó más que en preproducción (volumen de datos, estadísticas, otra carga en el almacenamiento) y el ajuste del tiempo y de la hora límite para el siguiente intento.

Siguientes pasos

• La guía de entornos de prueba explica cómo medir en preproducción el tiempo real del cambio y de su vuelta atrás.
• La de Oracle en hardware nuevo cubre el plan con el DBA, Data Guard y RMAN para cambios de servidor.
• La de parches de Windows Server sin cortar el servicio aplica las mismas ventanas a los parches de cada mes.
• La de publicar la aplicación clínica en Citrix ayuda en la reapertura y con la sesión que no abre en planta.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.