Qué vas a conseguir
Un entorno donde probar una actualización de la historia clínica, un parche del servidor o un cambio de integración antes de que llegue a la planta. En una plataforma que no puede pararse, el entorno de pruebas es lo único que separa un cambio de una incidencia a las tres de la mañana. Solo sirve si se parece a producción en lo que importa y si no contiene datos reales de pacientes.
Antes de empezar
- El inventario de la plataforma en producción: servidores, versiones, base de datos, integraciones (laboratorio, imagen, farmacia) y certificados.
- El responsable funcional de la aplicación y el proveedor: son quienes saben qué hay que probar y quienes firman.
- La política de protección de datos del centro y al delegado de protección de datos (DPD): los datos de salud son categoría especial en el RGPD.
- Capacidad en la plataforma virtual para un entorno más pequeño, pero con la misma arquitectura.
1. Lo que tiene que ser igual que producción
| Igual siempre | Puede ser distinto |
|---|---|
| Versión de la aplicación y de sus módulos | Número de servidores de aplicación |
| Versión del sistema operativo y nivel de parches | CPU y memoria (más pequeño) |
| Motor y versión de la base de datos, intercalación | Volumen de datos (un subconjunto) |
| Configuración de la aplicación y del servidor web | Nombres de host (con sufijo -pre) |
| Integraciones, aunque apunten a sus propios entornos de pruebas | Certificados (de la CA interna de pruebas) |
| Antivirus, agentes y GPO aplicadas | Alta disponibilidad (puede ser un solo nodo) |
Si el clúster o el balanceador forman parte del cambio, el entorno de pruebas los necesita también. Probar una conmutación en un solo nodo no prueba nada.
2. Los datos: nunca pacientes reales
- Datos ficticios generados por el proveedor o por un script para pruebas funcionales normales.
- Copia de producción enmascarada cuando hace falta volumen o casos reales (rendimiento, migraciones): se restaura en una red aislada, se enmascara y solo entonces se abre a los probadores.
- El enmascaramiento es estático: se cambian los datos en la base. El enmascaramiento dinámico de SQL Server solo oculta al consultar; el dato sigue ahí y no vale para un entorno de pruebas.
- Se enmascara todo lo identificativo: nombre, apellidos, DNI, número de historia, tarjeta sanitaria, teléfono, dirección y textos libres de notas clínicas (o se vacían).
Invoke-Sqlcmd -ServerInstance srv-sql-pre01 -Database HCE_PRE -Query "SELECT TOP 3 NHC, Apellido1, DNI, Telefono FROM Pacientes"NHC Apellido1 DNI Telefono--- --------- --- --------PRE000101 APELLIDO101 00000101T 600000101PRE000102 APELLIDO102 00000102R 600000102PRE000103 APELLIDO103 00000103W 600000103Si la comprobación muestra un solo nombre real, el entorno se cierra y se avisa al DPD. No se "arregla después".
3. Red aislada y accesos
- VLAN propia para el entorno de pruebas, sin rutas hacia los servidores de producción. Una prueba que escribe en el laboratorio real es una incidencia de seguridad del paciente.
- Las integraciones apuntan a los entornos de pruebas de los otros sistemas, o a simuladores.
- Acceso nominal y temporal para probadores y proveedor; cuentas de servicio distintas de las de producción.
- Copias de seguridad propias: un refresco fallido no debe obligar a pedir otra copia de producción.
4. El plan de pruebas y el visto bueno
El plan se escribe con el responsable de la aplicación, no lo escribe IT solo:
- Qué cambia y qué partes de la aplicación toca.
- Casos de prueba de los circuitos críticos: ingreso, prescripción, petición al laboratorio, alta.
- Pruebas técnicas: instalación, tiempo del cambio, reversión y rendimiento básico.
- Resultado de cada caso con quién lo probó y cuándo.
- Visto bueno firmado por el responsable funcional, que se adjunta a la petición de cambio antes de ir al CAB.
5. El ticket: "funcionó en pruebas y falló en producción"
Jueves, 06:10, tras la ventana de cambio. La actualización se aplicó y el módulo de farmacia da error en producción; en preproducción funcionó.
- Se aplica el plan de reversión si el error afecta a la atención y no hay solución en el tiempo acordado. Primero la plataforma, después la investigación.
- Se busca la deriva: qué es distinto entre los dos entornos. Lo habitual: un parche del sistema, un certificado, un cambio manual que nunca se documentó.
Compare-Object (Get-HotFix -ComputerName srv-hce-app01) (Get-HotFix -ComputerName srv-hce-pre01) -Property HotFixIDHotFixID SideIndicator-------- -------------KB5066835 <=Producción tiene un parche que preproducción no tiene. Se aplica en preproducción, se repite la prueba y se reproduce el error: ya hay causa para el proveedor.
- Se corrige el proceso: el entorno de pruebas entra en el mismo ciclo de parches que producción, una semana antes.
6. Lo que revisas cada mes
- Versiones y parches de producción y preproducción comparados, con las diferencias justificadas.
- Fecha del último refresco y resultado de la comprobación de enmascaramiento.
- Accesos al entorno: los temporales caducados, retirados.
- Cambios aprobados en el mes que se aplicaron sin pasar por pruebas, y por qué.
Siguientes pasos
- La guía de ISO 27001/NIS2/RGPD en IT explica el tratamiento de datos de salud y la gestión de cambios que pide la auditoría.
- La guía de PostgreSQL/MySQL/SQL Server cubre la restauración de bases de datos para el refresco.
- La guía de Backup y DR/BCP sitúa el entorno de pruebas en el plan de recuperación.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
An environment to test an electronic health record upgrade, a server patch or an integration change before it reaches the wards. On a platform that can't stop, the test environment is the only thing between a change and an incident at three in the morning. It only works if it matches production where it matters and holds no real patient data.
Before you start
- The inventory of the platform in production: servers, versions, database, integrations (laboratory, imaging, pharmacy) and certificates.
- The application's business owner and the vendor: they know what needs testing and they sign it off.
- The organisation's data protection policy and the data protection officer (DPO): health data is a special category under GDPR.
- Capacity on the virtual platform for a smaller environment, but with the same architecture.
1. What has to match production
| Always the same | Can differ |
|---|---|
| Application and module versions | Number of application servers |
| Operating system version and patch level | CPU and memory (smaller) |
| Database engine, version and collation | Data volume (a subset) |
| Application and web server configuration | Host names (with a -pre suffix) |
| Integrations, even if pointing to their own test environments | Certificates (from the internal test CA) |
| Antivirus, agents and applied GPOs | High availability (can be a single node) |
If the cluster or the load balancer is part of the change, the test environment needs them too. Testing a failover on a single node proves nothing.
2. The data: never real patients
- Fictional data generated by the vendor or a script for normal functional testing.
- Masked copy of production when you need volume or real cases (performance, migrations): it's restored on an isolated network, masked, and only then opened to testers.
- Masking is static: the data in the database is changed. SQL Server dynamic data masking only hides it at query time; the data is still there and won't do for a test environment.
- Everything identifying is masked: name, surnames, ID number, record number, health card, phone, address and free-text clinical notes (or they're emptied).
Invoke-Sqlcmd -ServerInstance srv-sql-pre01 -Database HCE_PRE -Query "SELECT TOP 3 MRN, Surname, NationalId, Phone FROM Patients"MRN Surname NationalId Phone--- ------- ---------- -----PRE000101 SURNAME101 00000101T 600000101PRE000102 SURNAME102 00000102R 600000102PRE000103 SURNAME103 00000103W 600000103If the check shows a single real name, the environment is closed and the DPO is told. It doesn't get "fixed later".
3. Isolated network and access
- Its own VLAN for the test environment, with no routes to production servers. A test that writes into the live laboratory system is a patient safety incident.
- Integrations point to the other systems' test environments, or to simulators.
- Named, time-limited access for testers and the vendor; service accounts separate from production.
- Its own backups: a failed refresh shouldn't mean asking for another production copy.
4. The test plan and sign-off
The plan is written with the application owner, not by IT alone:
- What changes and which parts of the application it touches.
- Test cases for the critical pathways: admission, prescribing, lab order, discharge.
- Technical tests: installation, change duration, rollback and basic performance.
- Result of each case, with who tested it and when.
- Sign-off by the business owner, attached to the change request before it goes to CAB.
5. The ticket: "it worked in test and failed in production"
Thursday, 06:10, after the change window. The upgrade was applied and the pharmacy module throws an error in production; in pre-production it worked.
- Run the rollback plan if the error affects care and there's no fix within the agreed time. Platform first, investigation second.
- Look for the drift: what is different between the two environments. The usual suspects: an OS patch, a certificate, a manual change nobody documented.
Compare-Object (Get-HotFix -ComputerName srv-hce-app01) (Get-HotFix -ComputerName srv-hce-pre01) -Property HotFixIDHotFixID SideIndicator-------- -------------KB5066835 <=Production has a patch pre-production doesn't. Apply it in pre-production, repeat the test and the error reproduces: now there's a cause to give the vendor.
- Fix the process: the test environment joins the same patch cycle as production, one week earlier.
6. What you review each month
- Production and pre-production versions and patches compared, with differences justified.
- Date of the last refresh and the result of the masking check.
- Access to the environment: expired temporary accounts removed.
- Changes approved in the month that were applied without testing, and why.
Next steps
- The ISO 27001/NIS2/RGPD en IT guide explains handling health data and the change management an audit asks for.
- The PostgreSQL/MySQL/SQL Server guide covers restoring databases for the refresh.
- The Backup y DR/BCP guide places the test environment in the recovery plan.
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 →