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:
- Qué se cambia, por qué y qué partes de la HCE toca.
- Resultado de las pruebas en preproducción, con el visto bueno del responsable funcional.
- Plan por pasos con horas (sección 5) y el criterio y el plan de vuelta atrás (sección 6).
- Procedimiento de contingencia y la lista de servicios avisados.
- Usuarios clave que validarán, y a qué hora estarán disponibles.
CambiosRFC-2026-0518Planificación
SistemaHCE producción (hce-app01/02, hce-db01, granja Citrix HCE)
Ventanamartes 17/11/2026, 02:00 – 05:00 (corte previsto 02:15 – 04:00)
Hora límite para decidir vuelta atrás03:30
Vuelta atrás probada en preproducciónSí, 35 minutos
Visto bueno funcionalresponsable HCE, 05/11/2026
Servicios avisadosUrgencias, UCI, Hospitalización, Laboratorio, Radiología, Farmacia, Admisión
Procedimiento de contingencia revisado con supervisión de enfermería
Enviar a CAB
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
| Momento | Qué | A quién |
|---|---|---|
| 3 semanas antes | Fecha, hora, duración y qué hacer | Todos los servicios, dirección |
| 1 semana antes | Recordatorio y procedimiento de contingencia | Supervisiones, jefes de servicio |
| Día anterior | Recordatorio con el teléfono de la guardia de IT | Supervisiones de guardia, urgencias |
| 30 minutos antes | Aviso de cierre en Citrix y llamada a las supervisoras | Usuarios conectados, supervisiones |
| Durante | Una llamada o un mensaje en cada punto de decisión | Supervisora de guardia, jefe de guardia |
| Al terminar | Sistema disponible, qué validar y cómo pasar lo de papel | Todas las unidades |
| Día siguiente | Resultado, incidencias y lecciones | CAB, responsable funcional, dirección |
- 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
| Hora | Paso | Quién | Punto de decisión |
|---|---|---|---|
| 01:00 | Listados impresos y visor de contingencia comprobado en cada unidad | Supervisiones, IT | Ir / no ir 1: contingencia lista |
| 01:30 | Copia de seguridad verificada y punto de restauración en Oracle | DBA | Copia correcta |
| 02:00 | Aviso final; aplicación deshabilitada en Citrix | IT | |
| 02:15 | Parada de la aplicación y de las integraciones de entrada | IT, integración | Mensajes en cola, no perdidos |
| 02:30 | Actualización de base de datos y aplicación | Proveedor, DBA | |
| 03:30 | Comprobaciones técnicas | IT, proveedor | Ir / no ir 2: seguir o volver atrás |
| 03:45 | Validación con usuarios clave | Usuarios clave | Ir / no ir 3: visto bueno clínico |
| 04:15 | Apertura en Citrix, integraciones en marcha | IT | |
| 04:30 | Aviso de disponibilidad a las unidades | Coordinador |
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 NOCREATE 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 AMSet-BrokerApplication -Name "HCE Produccion" -Enabled $falseGet-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 IMMEDIATESTARTUP MOUNTFLASHBACK 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:
- Buscar el paciente y abrir su historia; ver alergias y episodios anteriores.
- Registrar constantes y una administración de medicación.
- Prescribir y comprobar que la orden llega a farmacia.
- Pedir una analítica y comprobar que llega al laboratorio; recibir un resultado de prueba.
- Imprimir una etiqueta y una pulsera.
- 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-integracionactiveactivecurl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://hce.contoso.local/health200 0.412sjournalctl -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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
What you'll get
Taking a hospital's electronic patient record (EHR) down for an upgrade without care suffering: a window agreed with whoever works that night, a downtime procedure the wards know, a plan with times and decision points, a rehearsed rollback and validation by clinical staff before the system is accepted. And knowing what to do when the window overruns and the emergency department needs the system now.
Before you start
- The example platform: the EHR application on Red Hat Enterprise Linux servers, the database on Oracle and user access through Citrix. The same applies with other components.
- The change tested in pre-production, with its time measured and the rollback rehearsed, as in the test environments guide.
- The names of the decision makers: the EHR business owner, nursing management, the on-call medical lead, the DBA, the vendor and the on-call IT lead.
- The inventory of what depends on the EHR: laboratory, imaging, pharmacy, admissions, the integration layer and the label and wristband printers.
1. The window, agreed with the clinical services
In a hospital there is no hour without patients. There are hours with less activity and services that can prepare:
- The time: the early hours on a weekday are usually the least bad (for example, 2:00 to 5:00 on a Tuesday). Avoid nursing shift changes, pharmacy's unit-dose preparation and the laboratory's first-thing blood draws.
- With whom: nursing management and that night's on-call nursing supervisors, the on-call medical lead and the emergency department, the laboratory, radiology, pharmacy and admissions. Each says what happens to them without the system and what they need beforehand.
- The maximum duration: agree the total outage the hospital accepts and a cut-off time. If it isn't done by then, you roll back.
- The calendar: three or four weeks ahead, not clashing with other changes, bank holidays, an audit or a peak week (flu season, long weekends).
Make sure the on-call supervisors know the date before anyone else: they are the ones who organise the wards that night.
2. The change and its approval
The change request reaches the change advisory board (CAB) complete:
- What changes, why, and which parts of the EHR it touches.
- Pre-production test results, with the business owner's sign-off.
- The step plan with times (section 5) and the rollback criterion and plan (section 6).
- The downtime procedure and the list of services notified.
- The key users who will validate, and when they will be available.
ChangesRFC-2026-0518Planning
SystemEHR production (hce-app01/02, hce-db01, EHR Citrix farm)
WindowTuesday 17/11/2026, 02:00 – 05:00 (planned outage 02:15 – 04:00)
Cut-off for the rollback decision03:30
Rollback rehearsed in pre-productionYes, 35 minutes
Business sign-offEHR owner, 05/11/2026
Services notifiedEmergency, ICU, Wards, Laboratory, Radiology, Pharmacy, Admissions
Downtime procedure reviewed with nursing supervisors
Submit to CAB
3. The downtime procedure
During the outage the hospital keeps working without the EHR. That is prepared:
- Paper forms per service: medical orders, vital signs charts, medication administration, laboratory and radiology requests, admission and discharge. Each unit has its downtime folder and knows where it is.
- Read-only (downtime) viewer: a lookup copy of the clinical data, on a separate server or one PC per unit, refreshed periodically and still available when the EHR is down. Check the afternoon before that it has refreshed and opens in every unit.
- Printed lists before the outage, in each unit: inpatients with bed, allergies, active medication and its administration schedule for the window's hours. One hour before, not the afternoon before: that way they include the night's admissions.
- Identification and labels: admissions and the emergency department have downtime wristbands and labels, or a provisional number for patients arriving during the outage.
- Back-entry: what was recorded on paper is entered into the EHR afterwards. Who does it, in what order (medication and orders first) and by when is written down before the window.
If the downtime viewer or the lists aren't ready on time, the window doesn't start. That is the first decision point.
4. Communication: before, during and after
| When | What | To whom |
|---|---|---|
| 3 weeks before | Date, time, duration and what to do | All services, management |
| 1 week before | Reminder and downtime procedure | Supervisors, heads of service |
| The day before | Reminder with the IT on-call number | On-call supervisors, emergency |
| 30 minutes before | Closing notice in Citrix and a call to the supervisors | Connected users, supervisors |
| During | A call or message at each decision point | On-call supervisor, on-call lead |
| At the end | System available, what to check and how to back-enter paper | All units |
| Next day | Outcome, incidents and lessons | CAB, business owner, management |
- One single IT person talks to the supervisors during the window. Engineers work; the coordinator informs.
- The Citrix notice is no substitute for the call: at two in the morning nobody reads an on-screen message.
5. The step plan, with times and decision points
| Time | Step | Who | Decision point |
|---|---|---|---|
| 01:00 | Lists printed and downtime viewer checked in each unit | Supervisors, IT | Go / no-go 1: downtime ready |
| 01:30 | Backup verified and Oracle restore point | DBA | Backup good |
| 02:00 | Final notice; application disabled in Citrix | IT | |
| 02:15 | Application and inbound interfaces stopped | IT, integration | Messages queued, not lost |
| 02:30 | Database and application upgrade | Vendor, DBA | |
| 03:30 | Technical checks | IT, vendor | Go / no-go 2: continue or roll back |
| 03:45 | Validation with key users | Key users | Go / no-go 3: clinical sign-off |
| 04:15 | Opened in Citrix, interfaces running | IT | |
| 04:30 | Availability notice to the units | Coordinator |
The technical steps that make rollback possible, before touching anything:
SELECT name, log_mode, flashback_on FROM v$database;NAME LOG_MODE FLASHBACK_ON--------- ------------ ------------------HCEPRO ARCHIVELOG NOCREATE 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 AMSet-BrokerApplication -Name "HCE Produccion" -Enabled $falseGet-BrokerApplication -Name "HCE Produccion" | Select-Object Name, EnabledName Enabled---- -------HCE Produccion False- A guaranteed restore point needs the database in ARCHIVELOG and space in the fast recovery area (FRA). The DBA estimates how much the upgrade will generate.
- Disabling the application in Citrix stops new sessions; open ones are closed with a warning after the call to the supervisors.
- Inbound interfaces (laboratory, admissions) are stopped so that messages queue, not get lost. Note each queue's depth before and after.
6. Rollback
- The criterion, written beforehand: if by the cut-off (03:30) the technical checks haven't passed, you roll back. It isn't negotiated at 03:29.
- The plan, rehearsed in pre-production with its time: stop the application, take the database back to the restore point and the application back to its previous version (packages, files or the snapshot of the application VMs).
SHUTDOWN IMMEDIATESTARTUP MOUNTFLASHBACK DATABASE TO RESTORE POINT antes_rfc0518;Flashback complete.ALTER DATABASE OPEN RESETLOGS;Database altered.- After a rollback you validate exactly as after the change: the old system has to work too before it is opened.
- With the final sign-off, the DBA drops the restore point (
DROP RESTORE POINT antes_rfc0518;): forgotten, it fills the FRA within days.
7. Validation with key users and monitoring afterwards
The key users are clinical staff (a nurse, an on-call doctor, someone from admissions and the laboratory) who know the workflows and are booked for the planned time. With a test patient in production, they follow a short script:
- Find the patient and open their record; see allergies and previous episodes.
- Record vital signs and a medication administration.
- Prescribe and check the order reaches pharmacy.
- Request a blood test and check it reaches the laboratory; receive a test result.
- Print a label and a wristband.
- Each step signed with name and time on the validation sheet.
The technical checks go first, in parallel:
systemctl is-active hce-app hce-integracionactiveactivecurl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://hce.contoso.local/health200 0.412sjournalctl -u hce-app --since "02:30" -p err --no-pager | tail -n 5-- No entries --- After opening: the integration queues drain, response times are compared with those measured before the change and monitoring alerts again. The window's silence expires on time, as in the monitoring and alarms guide.
- On-call IT reinforces the first hours of the morning shift: that is when the whole hospital logs in at once.
8. The ticket: "the window is overrunning and the emergency department needs the system"
Tuesday, 03:40. The database upgrade was due to finish at 03:15 and is at 80 %. The on-call supervisor calls: the emergency department has five patients waiting, the downtime viewer doesn't show the tests of a patient admitted at 02:30, and the on-call lead asks when the system is coming back.
- This is decision point 2, ten minutes late. The coordinator gets the vendor, the DBA, the on-call IT lead and the on-call medical lead (or whoever management named as the window's clinical lead) on one call.
- Facts, not impressions: how much is left according to the vendor and how reliable that is; how long the rollback takes (35 minutes rehearsed); whether rollback is still possible from where the upgrade is.
- The options:
- Continue: if 15 minutes remain and the estimate is solid, the new system could be ready in 45 minutes with validation.
- Roll back: the old system in about 50 minutes with validation, and the change for another window.
- Who decides: IT and the vendor say what is possible and how long it takes; the clinical lead decides whether the hospital can stay in downtime for that long. If the vendor's estimate has already failed once, the default option is the written one: roll back.
- Meanwhile, downtime procedures are reinforced: the emergency patient is treated on paper with a direct call to the laboratory for their results. Nobody waits for the system to treat a patient.
- Communicate the decision to the supervisor with a concrete time ("system available at 04:35") and call if it changes. A time missed twice is worth less than none.
- Afterwards: the paper record is back-entered into the EHR, starting with the emergency department. In the change review, why the step took longer than in pre-production (data volume, statistics, other load on storage) and the adjusted time and cut-off for the next attempt.
Next steps
- The test environments guide explains how to measure the real time of the change and its rollback in pre-production.
- The Oracle on new hardware guide covers the plan with the DBA, Data Guard and RMAN for server changes.
- The Windows Server patching without downtime guide applies the same windows to monthly patching.
- The publishing the clinical app in Citrix guide helps with reopening and with the session that won't open on the ward.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →